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express business rules) to allow calling functions, maintain- 
ing functions, and providing of an execution framework for 
functions. In one embodiment, there are a niunber of func- 
tions to be maintained. An object technology infrastructure 
is formed to store data and metadata for the functions. For 
example, metadata about a function can include data 
describing what that function does, a "cost" associated with 
that function, how to execute that function, the input and 
output parameters required by that function. The exposure of 
the metadata regarding the functions' input and output 
parameters allows an engine to track input/output relation- 
ships between the functions and, in essence, define the order 
of execution. 
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METHOD AND APPARATUS FOR 
MANAGING FUNCTIONS 

CROSS-REFERENCE TO RELATED 
APPUCAnONS 

Not Applicable. 

BACKGROUND OF THE INVENTION 

1. Field of the loveotion 

The invention relates to the field of computer systems. 
More specifically, the invention relates to function manage- 
ment. 

2. Badcground Information 

Most corporate systems built to support certain business 
practices involve writing application logic within the appli> 
. cation. The creator of the application writes the necessary 
programs in a language of personal desire and adds business 
specific rules for the application as a part of the module that 
contains the apphcation. Thus, the business rules of an 
enterprise have been and are added overtime by different 
programmers; at different times; using different program- 
ming languages; for different applications of an enterprise; 
etc. This type of application development does not lead itself 
to maintainable components. Any updates to a business rule 
might impact the overall application. The application logic 
is not reusable for other enterprise wide appLications, as it is 
contained within each application. This results in rewriting 
the same logic for different applications. 

Certain other application programmers write the logic 
specific for the business as a separate module and link to it 
the other components of the application during execution or 
during compilation. Even thou^ this allows for reuse of 
code, the corporations have to maintain a repository of these 
modules. There is rarely any documentation, much less 
transfer of knowledge to other departments regarding a 
module developed in a given department However, ao 
application developer must know the existence of the mod- 
ules housing the business rules, as well as how to link them 
into the application. In addition, the functions in these 
modules have to be called explicitly. This type of application 
development does not lend itself to support ''call on need^ 
type of functions. 

Other applications require the functions representing 
business rules to match a specified prototype. These fuDC- 
tions are accessible through a data structure such as a hash 
structure (e.g., table, tree, graph, etc.) that contains function 
pointers. The dynamic selection of functions is supported 
through the use of a hash function that indexes into the hash 
structure. There are numerous search types (e.g., search by 
name, search by type) possible based on the native and 
complex data structures. This approach has several limita- 
tions. For example, additional data structures are required to 
support each search type. Also, it is difiEcult to maintain 
multiple data structures and keep them in sync for any 
updates/changes. In addition, this approach does not remove 
the need for extensive documentation and transfer of knowl- 
edge for the modules to be re-used. 

Furthermore, there is no reasonable mechanism to search 
a business rule on the basis of its' output. Particularly, each 
business rule requires inputs and outputs. Before executing 
a given business rule, a programmer must provide the inputs 
for that business rule. It can be the case that one or more 
inputs of a given business rule is ao output of a different 
business rule. Thus, in collecting the inputs for a given 
business rule, a user may be required to manually identify 
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the collection of business rules whose outputs will provide 
the inputs for that given business rule. Particularly, a string 
of biisiness rules, each of whose input is the output of 
another, may need to be executed to acquire the input needed 

5 for the business rule of interest. However, as these business 
rules are being added to the system, there is no good 
mechanism or infrastructure to track the input/output rela- 
tionships between these business rules. 

The lack of ability to track the input/output relationships 

10 between these business rules makes them difiBcuIt, if not 
impossible, to maintain and/or reuse. Thus, there is no 
reasonable mechanism by which a user can locate, much less 
execute, the business rules across the enterprise required to 
provide the inputs for a given business rule of interest. For 

15 example, a user interested in a particular input that is 
provided by a business rule would need know of that 
business rule, be able to locate that business rule, and know 
the format to call that business nile. 

Additionally, since the business rules interface with the 
integration sources and/or other business rules of the 
enterprise, changing a given integration source and/or busi- 
ness rule can affect any number of other integration sources 
and/or business rules. However, it often cannot be deter- 
mined what business rules and/or other integration sources 
will be affected by such changes. For example, although 
input/output relationships exists between the business rules, 
there is no mechanism for readily exposing these relation- 
ships. As a result, programmers are reluctant to make any 
changes, but instead attempt to extend integration sources 

^ and/or write new business rules. 

BRIEF SUMMARY OF THE INVENTION 

A method and apparatus for managing functions (e.g., that 
express business rules) to allow calling functions, maintain- 
ing functions, and providing of an execution framework for 
functions is described. According to one embodiment of the 
invention, a machine readable medium is provided having 
stored thereon a function, a first object, a second object, and 
^ an action unit. The function requires a set of one or more 
input parameters. The first object includes a structure storing 
a key for each of the input parameters to the function. In 
addition, the first object includes an action method, which 
when applied by a processor, causes that processor to invoke 
the action unit. The second object includes: 1) a first 
structure to store data for identifying, for one or more of the 
input parameters, the corresponding key and a value for that 
input parameter; and 2) a second structure identifying the 
first object. In addition, the second object includes an 
execute method, which when applied by a processor, causes 
that processor to apply the action method. The action unit 
includes instructions, which when executed by a processor, 
cause that processor to, access the values in the second 
object and invoke the function using those values as input 
parameters. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The invention may best be understood by referring to the 
following description and accompanying drawings which 
are used to illustrate embodiments of the invention. In the 
drawings: 

FIG. lA is a bbck diagram illustrating a system according 
to one embodiment of the invention. 

FIG. IB is a block diagram illustrating the relationship 
65 between the functions being tracked, metadata objects, 
execution objects, and manager objects according to one 
embodiment of the invention. 
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FIG. 2A is a block diagram Ulustratiag an exemplary FIG. 19 is a flow diagram iUustraling the operation of the 

parameter kind class hierarchy according to one embodi- EXECUTE method according to one embodiment of the 

meot of the invention. invention. 

nG. 2B is a block diagram ilhist^^^^ Pjq 20 is a block diagram illustrating the 

class205 accordmgtooneembodmientofthemvention. 5 p^RAMETER.SATISFY method according to one 

FIG. 2C is a block diagram illustrating a REGISTER class embodiment of the invention. 
210 according to one embodiment of the invention. 

FIG. 3 is a block diagram ilhistrating the manner in which 21 is a conceptual diagram Ulustrating exemplary 

a register object is used according to one embodiment of the execution paths accordmg to one embodiment of the mven- 

invention. tion. 

FIG. 4 is a block diagram illustrating the relationship of 

metadata objects to the action units of FIG. 3 according to DETAILED DESCRIPTION OF THE 

one embodiment of the invention. INVENTION 

FIG. 5 is a block diagram illustrating a metadata class 15 ,,,„.,. . -i* • ., * 

according to coe embodiment of the invcDtion. '° foUowingdcscnption, numerous specdic details arc 

FIG. 6A is a flow diagram illuslraUng the defimtioo of a f '° P™^?^" Ihotough understandmg of the mven- 

, J - . c . I * ■ u J- tion.' However, it is understood that the invention may be 

class and instances of that class accordmg to one embodi- • . • i. ' . -n . , . - . 

ment of the invention practiced without these specinc details. In other instances, 

^„ ^ . „ ' .„ . - 20 well-known circuits^ structures and techniques have not 

^9;.'® f.» «7 ''fSram lUustratmg cerUm^pects of 
the mitialization of a class according to one embodiment of 

the invention. Overview 

FIG. 6C is a flow diagram illustrating the initialization of A method and apparatus for managing fiinctions (e.g., that 

an instance of a class according to one embodiment of the ^5 express business rules) to allow calling functions, maintain- 

invention. ing functions, and providing of an execution framework for 

FIG. 7 is a conceptual diagram iflustrating an exemplary functions is described. In one embodiment, there are a 

class hierarchy structure according to one embodiment of number of functions (e.g., C++ code, set of SQL statements, 

the invention ®^^ ) ^ maintained. An object technology infrastructure is 

FIG. 8 is a conceptual diagram illnstrating the instances 30 'J". J^^ 

structure according to one embodiment of the invention. '^^^^ 

^ . Other data. For example, metadata about a function can 

FIG. 9 IS a block diagram lUustraUng an execution class ^^^^^ ^^j^ describing what that function does, a "cost" 

accordmg to one embodunent of the invention. associated with that function, how to execute that function, 

FIG. 10 is an exemplary block diagram illustrating the the input and output parameters required by that function, 

relationship between an execution object and its' underlying Jhe exposure of the metadata regarding the functions' input 

function. and output parameters allows an engine to track input/output 

FIG. IIA is a block diagram illustrating a context class relationships between the functions and, in essence, define 

1100 according to one embodiment of the invention. the order of execution. For example, assume there is a 

FIG. IIB is a btock diagram illustrating a MANAGER 40 fiAoction A that requires a Name as the input and that 

class according to one embodiment of the invention. provides an Id as the output, and a function B that requires 

FIG. 12 is a block diagram Uhistrating an example in ^J^^ ^^"^ that provides a street addre^ as the 

which the parameters for the underlying function are con- °^'P"*- Smce the output of function A can satisfy the input 

taincd within a manager object according to one embodi- ^"^^^o" . ^"'^^^^ ^ ^fP^f^ j^/"^ 

ment of the invention. 4S ^ "^P^^^ ®- ^ relationship is defined 

n^i^- a A' 11 » * .u fu within the engine between functions A and B when these 

FIG. 13 is a flow diagram lUustratmg the operation of the n ^. j * 

SET_PARAM method of an execution object according to arc added to the system, 

one embodiment of the invention. Th"* spring of "fiinction meudato" allows the dynamic 

FlG.Misaflowdiagramillustratingtheoperationofthe 'J^'^u.^^ execute on 

GET PARAMmethod^rdingtooneembidimentofthe » demand^If the engme re^^ves a retpicsl (e.g. a r«j,uest fc 

invention a set of fields), an execution plan can be created by deter- 

«1 . „ J. .„ . . . , ^ mining the functions to be processed based on their inputs 

FIG. 15 is a flow diagram illustrating the operation of the ^^^ ^^ identified by the function metadata. Multiple 

NEW^EXEOmON method accordmg to one embodiment execution trees, plus multiple execution paths within the 

of the invention. ... , 55 same tree can be identified to satisfy the request. Based on 

FIG. 16 is a flow diagram illustrating the operation of the various parameters, one of the execution paths can be 

FIND_BY_NAME method according to one embodiment picked. 

of the mvention, example, assume the functions in Table 1 arc avail- 

FIG. 17 is a flow diagram illustratmg the operation of the ^ble. In addition, assume that a user has avadable a particu- 

FIND_BY_NEED method according to one embodiment ^ ^3^^ fo^ ^jjat user wants to acquire the associated 

of the invention. primary child's name. Accordingly, the fiinctions of Table 1 

FIG, 18A is a part of a flow diagram illustrating the form a tree (A to B, C and F; from both B and C to D; from 

operation of the SATISFY_RELATIONSHIP routine D to E; and firom F to E) and three execution paths 

according to one embodiment of the invention. (A-»B-»D-*E, A-»C-*D-»E, and A-^F-^E) (See FIG. 

FIG. ISb is the remainder of a flow diagram illustrating 65 21). Note that function G is not included in the trees as it is 

the operation of the SAnSFY_JlELAnONSHlP routine not required to satisfy the request Thus, function G signifies 

according to one embodiment of the invention. that the rules are executed only on demand. 
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TABLE 1 


Function 


Input 


Output 


A 


Name 


[d, Best Name 


B 


Id 


Street Address 


C 


Best Name 


Street Address 


D 


Street Address 


Spouse's Name 


E 


Best Name, Spouse's Name 


Primary Child's Name 


F 


Id 


Spouse's Name 


G 


Best Name 


Best Date of Biitb 



The above example is a simple query* As queries get more 
complicated and the number of outputs increase, more and 
longer trees can be created. 

This storing of function metadata also enables impact 
analysis and maintenance of the functions thereby satisfying 
the need to consider both (one shot) development and 
(continual) evolution; that' is, integration of functions with 
adaptiveness during application development and mainte- 
nance. 

While the concepts described below regarding the man- 
aging of functions can be applied to any simation where 
functions are to be managed, the invention will be described 
with reference to the management of functions that represent 
business rules for an enterprise. However, it should be 
understood that the invention is not limited to the manage- 
ment of functions that rq)r6sent business rules. 

FIG. lA is a block diagram illustrating a system (e.g., a 
transactional system, a data warehouse system, etc.) accord- 
ing to one embodiment of the invention. FIG. lA represents 
a set of one or more disparate integration sources lOOA-i 
(e.g., relational databases, CORBA, conversion 
applications, etc.) being used by an exemplary enterprise. In 
addition, FIG. lA shows an integratk)n layer formed with 
object technology providing an integrated view of the enter- 
prise. 

FIG. lA also shows a model engine through which 
administrator(s) and user(s) can access the integration layer. 
The model engine is a library of functions that allows for 
interfacing (e.g., creating, searching, navigating, browsing, 
manipulating, etc.) with the objects in the integration layer. 
For example, the administrator(s) can develop and maintain 
the integration layer, as well as define security access. The 
user(s), for example, can navigate and/or query the model 
provided by the integration layer. Thus, the model engine 
can include various administrator and user interfaces (e.g., 
business tools, custom front-end tools, custom back-end 
tools, etc.). Of course, the integration layer and model 
engine are stored and executed on a computer system (either 
a single computer or a computer network). Such a computer 
system stores and communicates (e.g., the model engine 
and/or integration layer) using machine readable media, 
such a magnetic disks, optical disks, random access memory, 
read only memory, carrier waves, signals, etc. As with any 
method in an object, the code for a given method can be: 1) 
in the object itself; or 2) stored as part of the model engine 
and referenced by the object. 

As described later herein, the integration layer provides an 
adaptive integrated view of the enterprise by allowing 
related items (e.g., functions representing business rules) 
across the enterprise to be located and applied. Through 
these interrelationships the result of changing an integration 
source and/or part of the integration layer can be determined. 
This ability provides for reusability of existing items and for 
maintenance of the system. 

The integration layer incx)rporates certain naming stan- 
dards and procedures. While the integration layer can 
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include various objects (e.g., relationship objects as 
described later herein), in one embodiment of the invention 
the integration layer includes action units, metadata objects, 
execution objects, and one or more manager objects. 

S FIG. IB is a block diagram illustrating the relationship 
between the functions being tracked, metadata objects, 
execution objects, and manager objects according to one 
embodiment of the invention. In one embodiment of the 
invention, there are a number of different functions to be 

10 tracked and used. Each of these functions has a set of one or 
more input parameters and a set of one or more output 
parameters. The set of objects (metadata, execution, and 
manager objects) is formed for tracking, as well as providing 
other fimctionality, for the number of functions. 

15 For each function, at least one metadata object is formed 
to store metadata regarding the underlying function. A given 
metadata object can be associated with an underlying fimc- 
tion a number of different ways (e.g., through a reference 
directly to the function, through a reference to an action unit 

20 that provides an interface between the metadata object and 
its' underlying function, through storage of the function as 
a method in the metadata object, etc). Any such action units 
can be implemented in any programming language (e.g., C, 
C-i»i-, JAVA, etc.), and can be used to allow a common 

25 signature to be used for all functions. 

By way of example, FIG. IB shows action units 105A-i. 
Each of the action units 105A-i is associated with a function. 
For example, the action unit 105A identifies an external 
function 102 (e.g., legacy code and/or new code from one of 

30 the disparate integration sources io FIG. lA), whereas the 
action unit 105B contains a function referred to as an 
internal function. 

In addition, FIG. IB shows metadata objects 120A-i 
associated with underlying fimctions. Particularly, metadata 

35 objects 120A and B respectfully identify action units 1Q6A 
and B. Additionally, FIG. IB shows metadaU object 120C 
directly stores one of the functions (also referred to as an 
internal function), and therefore does not need an action 
unit. Among other things, a metadata object can store 

40 information describing the input and output "parameter 
kinds'* to it's underlying function. It is worthwhile to note 
that the term parameter kind is not used herein as synony- 
mous with data type. Rather, the phrase parameter kind 
refers to a type of information (e.g., name, street address, 

45 Id). Thus, two different parameter kinds (e.g., name and 
street address) may share the same data type (e.g., string). 

A metadata object typically does not contain the values to 
be used as input parameters to the underlying function. 
Rather, an execution object is formed to maintain a context 

50 (e.g., input parameter values and resulting output parameter 
values) for an underlying function. As such, one or more 
execution objects may be associated with each METADATA 
object. FIG. IB shows EXECUTION objects 125A-x-125i- 
X. Particularly, FIG. IB shows EXECUTION objects 

55 125A-A through 125A-I identifying METADATA object 
120A, EXECUTION object 125B identifying METADATA 
object 120B, EXECUTION object 125C identifying META- 
DATA object 120C, and EXECUTION object 125i identi- 
fying METADATA object 120/. 

60 FIG. IB also shows a manager object 130 identifying each 
of the execution objects. As described later herein, a man- 
ager object can be used, among other things, to track 
execution objects and store contexts for execution of the 
underlying functions. 

65 According to this structure, an execution object will 
maintain a set of input parameter values to be used during 
execution of an underlying function which is identified 
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through a metadata object. For example, in one embodiment 
of the invention, an execution object includes a method 
which, when applied, causes the application of a method in 
the associated metadata object. The method in the associated 
metadata object causes the execution of the instructions in 
the corresponding action unit. Execution of the instructions 
in the corresponding action unit cause the values for the 
input/output parameters maintained by the calling execution 
object to be used during the execution of that action unit's 
associated function. 

The indirection provided by the metadata objects is used 
to expose metadata regarding the underlying functions. The 
exposed metadata can include data describing the input and 
output parameter kinds of the underlying function. As 
described later herein, tbe exposed metadata regarding input 
parameter kinds can be used to identify whether a calling 
execution object has values for each of the input parameters 
of the' uhderlyitig * function. Furthermore, 'if the' calling 
execution object does not have values for the input param- 
eters of the underlying function, the metadata in other 
metadata objects describing the output kinds of their under- 
lying functions can be used to identify functions that would 
supply values for the missing input parameters. 

While certain aspects of tbe invention have been 
described in this overview, the invention is not limited to 
these aq)ects and various other aspects of the invention are 
described later herein. Furthermore, while one embodiment 
is described with lefecence to object oriented technology* it 
is understood that relational table based technology could be 
used. 

Registering Functions with tbe Integration Layer 

FIGS. 2A-C are block diagrams illustrating part of an 
exemplary object oriented infrastructure for the integration 
layer of FIGS. lA-B according to one embodiment of the 
invention. In one embodiment of the invention, keys are 
used to distinguish amongst the various functions being 
tracked by the integration layer, as well as providing a 
naming convention for the input and output parameter kinds 
of those functions. Thus, a first set of keys is used to 
distinguish functions being tracked by the integration layer, 
while a second set of keys is used to distinguish parameter 
kinds to those funaions. Since keys are used for distinguish- 
ing both tbe functions and parameters, the same object 
oriented classes can be used for both sets of keys. 

With regard to the set of keys used to disdnguish the 
parameter kinds, each function being tracked by the inte- 
gration layer can have one or more input parameters and one 
or more output parameters. A naming convention is used for 
the different parameter kinds used by tbe functions. Different 
functions may share one or more of the same parameter 
kinds. To illustrate, consider the previous example where 
function A has as parameters an Id and a street address, while 
function B has as parameters an name and a street address. 
In this example, hinaions A and B share the street address 
parameter (they share the same parameter kind). In addition, 
this example has three parameter kinds (Id, street address, 
and name). 

To provide a conceptual description, assume a mathemati- 
cal set (a set not containing duplications) containing the 
parameter kinds of all the functions being tracked by the 
integration layer. Each of the now unique parameter kinds in 
the mathematical set is assigned a unique key. As such, there 
is now a set of unique keys, one key for each parameter kind 
used by the functions being tracked by the integration layer. 

In one embodiment of tbe invention, a class is formed for 
each parameter kind and the dass name operates as the key 
for that parameter kind. Furthermore, these parameter kind 
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classes can form a parameter kind class hierarchy. FIG. 2A 
is a block diagram Ulustrating an exemplary parameter kind 
class hierarchy according to one embodiment of the inven- 
tion. As is well known in the art, classes can be made up of 
5 structures and/or methods. The structures can take any form 
(e.g., link list, array, tree, etc.). 

FIG. 2A shows a PARENT^ARAMETER class 200 
from which parameter kind classes 220, 225, and 230 are 
derived. In addition, FIG. 2A shows that parameter kind 
classes 240, 245, and 250 are derived from parameter kind 
class 220. Each of the parameter kind classes in FIG. 2A is 
given a name that operates as the key for that parameter 
kind. To continue the example from above, the keys assigned 
the parameter kind classes of FIG. 2A arc show in Table 2 
(note that the Best Date of Birth is not shown in FIG. 2Afor 
lack of space in tbe Figure). In other words, the parameter 
kind class names are used as global labels for identifying the 
parameter kinds of the functions being tracked by the 
integration layer. 



25 



TABLE 2 


Paiameter Kind Class 


Name/Key 


220 


Name 


240 


Bcst^Namc 


245 


%»use's_Name 


250 


Primary_Child*8_Nanie 


225 


id 


230 


Street_Address 




BcsL-Date—oC-Birth 



30 



Each of the parameter kind classes includes a CLASS- 
PARENT_LABEL method. The CLASS-PARENT_ 
LABEL method is used for associating labels with instances 
of different classes (similar to the ISA method commonly 

35 found in object oriented programming). In one embodiment, 
die CLASS-PARENT_XABEL method aids in the creation 
of a set of object tracking structure(s) that provide, among 
other things, the ability to distinguish which objects in the 
integration layer are N^ETADAIA objects. The operation of 

40 the CLASS-PARENT__LABEL method will be described 
later herein. 

FIG. 2B is a block diagram ilhistrating a KEY_VALUE 
class 205 according to one embodiment of the invention. In 
the embodiment shown in FIG. 2A, the KEY_VALUE class 

45 includes a KEY_STORAGE structure and a VALUE_ 
STORAGE structure. The KEY_STORAGE structure is 
used to store a key or a pointer to key (e.g., an instance of 
a parameter kind class), while the VALUE_STORAGE 
structure is used to store a current value corresponding to the 

50 key stored in the KEY_STORAGE structure. Key value 
objects are know in the art (e.g., they are used in data 
structures known as dictionaries). 

As stated above, a first set of keys is used to distinguish 
functions. During operation, certain embodiments use key 

55 value objects to track functions. Particularly, a KEY_ 
VALUE object can store the key assigned a function (KEY_ 
STORAGE) and a pointer to that function (VALUE_ 
STORAGE). 

As also stated above, a second set of keys is used to 
60 distinguish parameter kinds. The KEY_VALUE objects are 
used to store parameter values for the different parameter 
kinds. Particularly, if it is desired to store a parameter value, 
a KEY.OBJECT is formed in which the parameter kind is 
stored in the KEY.STORAGE strucmre and the parameter 
65 value is stored in tbe VALUE_STORAGE structure. 

FIG. 2C is a bbck diagram illustrating a REGISTER class 
210 according to one embodiment of the invention. The 
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REGISTER class 210 includes an ACnON_TRACKING 
slrucnire. The ACnON_TRACKlNG structure is a collec- 
tion of KEY_VALUE objects. In addition, the REGISTER 
class includes a REGISTER^CTION method and a 
GET_J^CnON method. As described below, an instance of 
the REGISTER class 210 is used for initially tracking the 
functions. 

FIG. 3 is a block diagram illustrating the manner in which 
a register object is used according to one embodiment of the 
invention. FIG. 3 shows the action units 305a— i. In 
operation, a given function (whether new or existing) is 
assigned a key. Next, the REGISTER_ACnON method is 
applied using as input parameters the function's unique key 
and a pointer to that hinction's action unit. Application of 
the REGISTER^CnON method causes the creation of a 
KEY_VALUE object for the function, and storage of that 
KEY_VALUE object in the ACTION_TRACKING struc- 
hire of the REGISTER object. By way of example, FIG. 3 
illustrates that each of the action units 305a-/ has a corre- 
sponding KEY_VALUE object 310fl-i stored in the 
ACnON_TRACKING structure of a register object 300. In 
this manner, any function (whether internal or external) can 
be registered with the REGISTER object of the integrattoo 
layer. 

The GET_ACnON method receives as an input param- 
eter the unique key for one of the functions. Application of 
the GET_^CnON method returns a pointer to the action 
unit (or metadata object containing an internal function) for 
the function assigned the input key. 

While FIGS. 2A-B and 3 are used herein to describe one 
mechanism for registering functions with the integration 
layer, it is understood that various mechanisms can be used 
for this purpose. In addition, certain figures contained herein 
illustrate one or more objects stored in a collection (e.g., 
KEY_VALUE objects 310A-310i in the ACTION^ 
TRACKING structure). It is understood that most collec- 
tions actually store refcrmccs to the items in the collection, 
not the item themselves. Thus, the storing of an object in a 
collection can refer to the storing of a reference to that object 
in the collection. 
Metadata Class 

FIG. 4 is a block diagram illustrating the relationship of 
metadata objects to the action units of FIG. 3 according to 
one embodiment of the invention. As previously described, 
action units can be created for functions tracked by the 
integration layer, and the functions can be internal or exter- 
nal to the action units. At least one METADATA object is 
formed for each function, and therefore at least one META- 
DATA object is formed for each action unit. Each META- 
DATA object is used to store metadata regarding the under- 
lying function. In addition, each METADATA object 
includes one or more methods used to execute the underly- 
ing function as described later herein. As such, FIG. 4 shows 
a munber of metadata objects 400A-i. Each of the META- 
DATA objects 400A-i is associated with the one of the action 
units 305A-i having the matching letter. 

FIG. 5 is a block diagram illustrating a metadata class 
according to one embodiment of the invention. In particular, 
FIG. 5 shows a METADATA class 500, As with all classes 
described herein, the METADATA class may include more, 
less, and/or different structures and/or methods depending 
on the functionality desired. 

The MEXi\DATA class 500 includes the following struc- 
tures: NAME; CLASS_LABEL; INPUTS; OUTPUTS; 
ACnON_NAME; and ACTION_POINTER. The NAME 
structure of a metadata object has stored therein the imique 
key of the function for which that metadata object was 
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created. The CLASS.Jj\BEL structure of all metadata 
objects stores a label indicating that they are metadata 
objects. As described later herein, these labels are used by 
certain embodiments for locating those objects in the inte- 
5 gration layer that are metadata objects (and derivatives 
thereof). 

As previously described, each function being tracked by 
the integration layer can have one or more input parameters 
and one or more output parameters. The INPUTS structure 

10 of a metadata object stores a set of keys identifying the input 
parameter kinds of the function for which that rule metadata 
was created. Similarly, the OUTPUTS structure of a meta- 
data object has stored therein a set of keys identifying the 
output parameter kinds of the function for which that 

15 metadata object was created. In this manner, a metadata 
object contains metadata describing the input and output 
parameter kinds of the underlying function for which that 
metadata object was created. As described Utef herein, this 
metadata is used to provide different a^ects of the inven- 

20 tion. 

The ACnON_NAME strucUire is used during creation 
of a metadata object to store the name of the action unit to 
which it will eventually be associated. The ACTION_ 
POINTER of a metadata object stores a pointer to the action 

25 unit (if any) associated with the function for which that 
metadata object was created. 

The METADATA class also includes an ACTION and a 
CLASS-PARENT__LABEL methods. When an action unit 
is used, the ACTION method of a metadata object, when 

30 applied, causes the execution of the instructions in the 
corre^nding one of the action units (the action unit iden- 
tified by the ACnON_PTR structure). However, when a 
metadau object directly stores an internal function as a 
method, the action method is overridden with the internal 

35 function. The ACTION method receives as an input param- 
eter a pointer to an execution object. The operation of the 
ACTION method will be described later herein. 

As stated above, other types of function metadata can be 
stored in the metadata object. For example, the storage of 

40 metadata describing what a function does can be searched to 
allow users to interact more easily with the system. The 
storage of metadata describing a cost of a function is used in 
certain embodiments as described later herein to select 
between execution paths described above and later herein. 

45 The storage of metadata describing how to execute the 
underlying function can be used to provide the user with 
information needed to set up an execution enviroiunent for 
that function. In certain embodiments, metadata (e.g., text) 
describing what each parameter is used for (what that 

50 parameter means) is stored (e.g., the key stored is Best_ 
Name, while the description of what that parameter is used 
for might be "A parameter used to store the filing that 
occurs most often for an input name.") The storage of this 
text description regarding the parameters can be searched 

55 and/or read to allow users to interact more easily with the 
system. 

As stated above, certain embodiments use a set of object 
tracking structurc(s) to track certain of the classes of objects 
(including the METADATA objects) in the integration layer. 

60 The object tracking structure(s) can take a variety of forms 
and be created in a variety of different ways. FIGS. 6AS are 
used herein to describe one such mechanism. However, it is 
understood that the invention is not limited to the mecha- 
nisms described with reference to FIGS. 6A-8. Particularly, 

65 alternative embodiments could use indexes. 

FIG. 6A is a flow diagram illustrating the definition of a 
class and instances of that class according to one embodi- 
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meat of the inventioD. In ooe embodiment of the inventioD, embodiment of the invention. As shown in FIG. 7, the class 

it is contemplated that different programmers will be creat- hierarchy structure expresses in some form a top-down 

ing functions and objects at different times and/or for representation of the hierarchy of the classes with reference 

different integration sources. As a result, different program- to the class labels. E)uring block 630 of FIG. 6B, the parent 

mors that are not in direct communication (e.g. they are 5 label identified by the CLASS-PARENT_LABEL method 

working at different times, they arc working on different js used to identify the position of the parent class m 

projects, etc) will be adding functions and classes. For this hierarchy structure. SubsequenUy the class label is added to 

and other reasons, it is desirable to have a set of central class hierarchy structure in the appropnate manner to 

strucmre(s) for tracking the obj^^^ ^'^^^di^^^^^^ the class hierarehy 

To this end one or more object Uacking structures are lO ^^^^ ^ ^^^^^ 

created. While any number of different object iracfang ^^^^^^^ FIG. 8 is a conceptual diagram illustrating the 

strucmres could be used, a few examples of object tracking instances structure according to one embodiment of the 

stnicnires are given herein. For example, in one embodiment invention. The instances structure is a central repository 

of the invention a class label structure, a class hierarchy used to record all of the instances by class. As shown in FIG. 

structure, and an instances stnicUirc arc used. These excm- i5 each class label and the instances of that class are stored 

plary structures will be described in more detail below. in the instances structure. While any number of well known 

In block 600, a unique label for the class is created and techniques can be used for implementing the instances 

control passes to block 610. When'a'prograininer wishes'*^to structure, one embodiment of the invention uses a hasti ' 

create a class, the programmer first creates a label that is not dictionary. In addition, one embodiment of the invention 

being used. With reference to the exemplary object tracking 20 uses numbers as the labels for the classes, but associates 

strucmres mentioned above, the class label structure is a more descriptive labels with these number labels using 

centralized repository for the programmers to store labels features of a programming language, 

currently being used to distinguish the different classes. In The combination of the class hierarchy structure and the 

block 600, a given programmer and/or programming tool instances strucmre provides a mechanism by which all 

accesses the class label structure to select a class label that 25 instances of a class (e.g., the metadata class, the parent 

is not already being used. When the programmer identifies parameter class, etc.) and its derivatives (if any) can be 

a label that is not currently being used, the programmer adds identified. As previously described, alternative embodiments 

this label to the class label structure. can use different structures. For example, rather than using 

As shown in blodc 610, the class is declared and control the CLASS-PARENT_LABEL method, data identifying the 

passes to block 620. Since the general manner of defining a 30 labels of a class and of its' parent could be expressed as data 

class is well known, only those parts relevant to this dis- in a structure of the class. As another example, rather than 

cussion will be desoibed. In particular, assuming that the generating the class hierarchy and/or instances structure 

class of FIG. 5 is used, the programmer and/or programming during class and instance initialization, alternative embodi- 

tool will need to spedSy an overriding CLASS-PAR£NT_ ments require the class hierarchy and/or instances structures 

LABEL method. The CLASS-PARENT_LAB£L method is 35 be maintained by the programmers during the definition of 

written to output the label for the class (selected in block the class(es) and instance(s). As another example, rather 

600) and the label of the parent class of that class (if any). than having a class label structure, a class hierarchy 

Since the class is being defined, the parent for the class (if structure, and an instances structure, an alternative embodi- 

any) will be readily identifiable. As such, the label for the ment could combine one or more of these into one structure, 

parent of the class can so be identified and incorporated in 40 As another example, rather than using structure(s) that track 

the CLASS-PARENT_LABEL method. As described later all class and instances of the integration layer, an alternative 

herein, the CLASS-PARENT_LABEL method will be used embodiment could implement structures that track only 

during class initialization and instances initialization to certain classes and/or instances. As another example, rather 

update the object tracking structures. than implementing a class hierarchy stmcture, an exhaustive 

As shown in block 620, the manner of creating iiistance(s) 45 search using the bottom-up view of the class hierarchy 

of the class is declared. In one embodiment of the invention, provided by the CLASS-PARENT_LABEL methods can be 

the objects in the integration layer include INIT and used to locate class(cs) and any derivatives thereof. 

lNrnALI2^INSTANCES methods. The INIT methods FIG. 6C is a flow diagram illustrating the initialization of 

for the classes are all applied at runtime to perform class an instance of a class according to one embodiment of the 

initialization as described with reference to FIG. 6B, while 50 invention. For example, in the embodiment described above 

the INITIALIZE_JNSTANCES methods are applied during the IN1T1ALIZE_INSTANCES method is applied to create 

instance initialization as described with reference to FIG. the instance. In block 645, an instance of the class is created 

6C. and control passes to block 650. 

FIG. 6B is a flow diagram illustrating certain aspects of With reference to block 650 of FIG. 6C, the CLASS- 

the imtializalion of a class according to one embodiment of 55 PARENT_JLABEL method of the instance is applied to 

the invention. In block 625, an instance of the class is identify the label of the class. Block 650 is performed in the 

created (referred to herein as the class object) and control same manner as block 625. From block 650, control passes 

passes to block 630. to block 660. 

In block 630, the CLASS-PAR£NT_JJ\BEL method of In block 660, the instance is added to the object tracking 

the class object is applied to identity the label of the class 60 stmcture(s). To continue the description of the exemplary 

and the label of its' parent (if any). From block 630, control object tracking struchire(s), the label identified in block 650 

passes to block 640. is used to locate the instance's class in the instances struc- 

As shown in block 640 of FIG. 6B, the dass being ture. The name of the new instance is then added to the 

initialized is added to the object tracking struaure(s). lb instances structure under diat class label, 

continue the description of the exemplary object tracking 65 Execution Gass 

structure(s), FIG. 7 is a conceptual diagram illustrating an FIG. 9 is a block diagram illustrating an execution class 

exemplary class hierarchy structure according to one according to one embodiment of the invention. As previ- 
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ously described, an executioa object is used to maintain a METADATA object 1010: 1) stores in its INPUTS structure 
context for executing the underlying function. the keys "EMPLOYEE_NAME" and "EMPLOYEE^ 

The EXECUTION class 900 of FIG. 9 includes the NUMBER" (e.g., pointers to the class objects for the param- 
following structures: NAME; CLASS LABEL; PARAMS; eter kind dasses with these names); 2) stores in its OUT- 
METADArA_OBJECT_i>TR; and MANAGERJTR. As 5 PUTS structure the key «YEARLY_SALARY;" and 3) 
previously described, each execution object is associated fi"^^ ^^"^"^^ ' ^ 

with a metadata object. In one embodiment, the NAME ^^T^^r^ *u u- ^ tn,c * 

structure of an execution object contains the same data as the ^fffl^'^^^' EXECUTION object 1015 stores m its 
«««« ^♦^.^h,,^ #K« K^trrArkAXA ^k;^^ t« ,i ;c PARAMS Structure a key value object for the 

name strucmre of the METADATA ob^^^^ EMPLOYEE NAME and EMPLOYER^NUMBER 

associated. In altemauve embodiments the NAMEstructure 10 ^^^^^^ ^inS (KEY_VALUE objects 1020 and 1025). 
need not store the same data but rather a name to name KEY_VALUE objects 1020 and 1025 respectively 

look-up structure is used. The CLASS_LABEL structure of ^^^^ ^^^^ ^^^^ KEY_STORAGE structures the unique 
the EXECUTION class 900 is used for the same purpose as j^^y^ eMPLOYEE_NAME and EMPLOYEE_NUMBER. 
the CLASS_LABEL structure of the METADATA class. METADATA^OBJECT_PTR of the EXECUTION 

The PARAMS sUiicturc of an execution object is used to i5 object 1015 stores a pointer to the' METADATA object 1010. 
store a context for executing that execution object's under- gy ^ay of example, assume the EXECUTE method of the 
lying function. The PARAMS structure of a given execution EXECUTION object 1015 is applied. Responsive to appli- 
object is used to store a KEY_VALUE' object associated cation of this execute method, the METADATA^ 
with each input and output parameter of the underlying OBJECT_^PTR of the EXECUTION object 1015 is used to 
function, A KEY_VALUE object associated with a given 20 apply the ACTION method of the METADATA object 1010. 
parameter stores the key for that parameter kind and the The ACTION method has as an input parameter a pointer to 
value to be used as previously described. An example of the the calling execution object (EXECUTION c^ject 1015). 
PARAMS structure is later described herein with reference Application of the ACTION method causes the execution of 
to FIG. 10. the instructions in the SALARY_ACT10N 1005. Thus, the 

The METADArA^OBJECT_PTR structure is used for 25 SALARY^ACTI ON 1005 receives the pointer to the calling 
storing a pointer to the METADATA object for which that execution object (in this example, the EXECUTION object 
EXECUTION object was created. The MANAGERJTR 1015). 

structure of an execution object is used to stoie a pointer to Execution of the SALARY_^CTION unit 1005 causes 
a MANAGER object (if any). the following: 1) a variable TEMPI to be declared and set 

The EXECUTION class 900 also includes the following 30 to the vahie stored in the VALUE_JST0RAGE structiure of 
methods: SET_PARAM; GET_J>ARAM; EXECUTE; and the KEY_VALUE objert 102^, 2) a variable TEMP2 be 
PARAMETER_SAnSFY. While each of these methods is declared and set to the vahie contained in the VALUE_ 
further described later herein, a brief description of each is STORAGE structure of the KEY_VALUE object 1025; and 
provided here. Application of the SET_PARAM method 3) declaration of a variable TEMP9. In addition, the instruc- 
sets the value of a KEY_VALUE object associated with that 35 tions of the SALARY_ACT10N unit 1005 cause the 
execution object. As later described herein with reference to SALARY^FUNCTION 1000 to be called using: 1) TEMPI 
one embodiment of the invention, this KEY_VALUE object and TEMP2 as input parameters; and 2) TEMP3 as a storage 
may be stored as part of the PARAMS structure or as a part area for the output parameter. As such, the values for the 
of a context provided by a MANAGER object. input parameters for the SALARY_J^NCnON 1000 have 

Application of the GET_PARAM method returns a value 40 been read from the EXECUTION object 1015. 
associated with a parameter kind whose key is supplied as an Additionally, execution of the instructions in the 
input (e.g., from the PARAMS strucnire). Application of the SALARY^ACTION unit 1005 result in storing the value 
EXECUTE method causes the application of the action associated with TEMP3 in the VALUE_JSTORAGE struc- 
method from the metadata object identified by the ture of the KEY_VALUE object 1030. As such, the outputs 
METADATA_OBJECT_PTR. The PARAMETER^ 45 of the SALARY_FUNCTION are stored in the EXECU- 
SATISFY method returns values for parameter kinds whose TION object 
keys arc supplied as inputs. Manager Class 

FIG. 10 is an exemplary block diagram illustrating the FIGS. IIA-B are block diagrams illustrating two addi- 
rclationship between an execution object and its* underlying tional classes of the integration layer of FIG. lA according 
function. FIG. 10 shows an external function SALARY^ 50 to one embodiment of the invention. FIG. IIA is a block 
FUNCTION 1000, an action unit SALARY^J^CTION diagram illustrating a context class 1100 according to one 
1005, a METADATA object 1010, and an execution object embodiment of the invention. The context class includes the 
1015. following structures: NAME; KEY_VALUE_ 

The SALARY_FUNCnON is written to receive an COLLECHON; and EXECUT10N_COLLECnON. 
employee's name and an employee*s number, and to pro- 55 The NAME structure of a context object is used to store 
duce that employee's yearly salary. As such, the SALARY^ a came or label for that context object. The KEY_VALUE_ 
FUNCTION has for inputs: 1) a string labeled TEMPI for COLLECTION of the context class 1100 is used to store a 
the employee's name; and 2) an integer labeled TEMP2 for collection of KEY__VALUE objects. In particular, the 
the employee's employee number. In addition, the salary KEY__VALUE_COLLECTION is used to store KEY_ 
function provides a floating point output in TEMP3 for the 60 VALUE objects that associate values with parameter kinds 
yearly salary. As previously described, the input and output of functions (similar to the PARAMS structure). The 
parameter kinds ofevery function (including the SALARY^ EXECUTION_COLLECnON structure of the context 
FUNCTION) are assigned a unique key In the example of class 1100 is used to store a collection of EXECUTION 
FIG. 10, the tmique keys are "EMPLOYEE_NAME," objects. Each context object can be used for storing a 
"EMPLOYEE.JWMBER," and "YEARLY_S ALARY." 65 different context for executing and searching functions being 
As also previously described, a METADATA object stores tracked by the integration layer. The manner of using the 
metadata regarding the underlying function. As such, the context objects will be further described later herein. 



03/16/2004, EAST Version: 1.4.1 



us 6,3: 

15 

In one embodiment, the KEY_VALUE_COLLECnON 
structure k formed for efiBciency purposes. Particularly, the 
EXECUnON_COLLECnON structure stores the execu- 
tion object(s) for the context. The KEY_VALUE objects for 
that context are therefore stored in the PARAMS structure of 
those EXECUTION objects. The system stores the KEY_ 
VALUE objects from those PARAMS structures in the 
KEY_VALUE_COLLECTION structure to provide for 
more efficient processing. In an alternative embodiment, the 
KEY_VALUE_COLLECTION structure is not imple- 
mented. 

FIG. IIB is a block diagram illustrating a MANAGER 
class according to one embodiment of the invention. A 
manager object can be used for managing the execution 
objects. The MANAGER class 1110 includes the following 
structures: CONTEXT_COLLECTION; DEFAULT^ 
CONTEXT; EXECUTION^COLLECTION; and 
EXECUTION^PATH^COLLECnON, 

TTie CONTEXT_COLLECnON structure is used for 
storing a collection of context objects. Thus, the 
CONTEXT_COLLECTION structure can be used for stor- 
ing various contexts to be used when executing and search- 
ing different functions being tracked by the integration layer. 
The DEFAULT_CONTEXT structure is used to store data 
identifying one of the context objects stored in the 
CONTEXT_COLLECTION structure as the default con- 
text. The EXECUTION_COLLECnON is used to store a 
collection of execution objects managed by a MANAGER 
object. 

Id one embodimeat, the EXECUTION_COLLECnON 
suructure in the manager class is provided for efficiency 
purposes. Particularly, the execution objects for the manger 
object are stored in the context objects of the CONTEXT^ 
COLLECTION structure. The system associates those 
execution objects with the EXECUTION_COLLECTI0N 
structure to provide for more efficient processing. In an 
alternative embodiment, the EXECUTION. 
COLLECTION structure is not implemented as part of the 
manager class. 

The MANAGER class 1110 includes the following meth- 
ods: NEW_EXECUTION; FIND^y_NAME; F1ND_ 
^y_NEED; nND_BY_NAME_AND_EXECUTE; and 
FIND_5y_NEED _^AND_EXECUTE. Although each of 
the methods is described in further detail later herein, a 
quick overview is provided here. 

The NEW_EXECUTION method is used to create a new 
execution object. The FIND_^_NAME method is used to 
locate or create an execution object for a given function 
tracked by the integration layer. The FIND_^_NEED 
method requires as an input parameter a collection of 
parameter kinds for which output values are requested 
(referred to herein as needs). The FIND_^y_NEED method 
returns a collection of EXECUTION objects whose under- 
lying functions return as outputs the specified needs. The 
FIND_^_NAME_AND_EXECUTE and the FIND_ 
*y_NEED_AND_EXECUTE methods add the additional 
steps of applying the EXECUTE method from the returned 
EXECUTION objects. 

FIG. 12 is a block diagram illustrating an example in 
which the parameters for the underlying function are con- 
tained within a manager object according to one embodi- 
ment of the invention. FIG. 12 contains the SALARY^ 
FUNCTION 1000, the SALARY_ACnON 1005, and the 
METADATA object 1010 from FIG. 10. In contrast to FIG. 
10, FIG. 12 shows an execution object 1215. The 
METADArA_OBJECT_PTR of the EXECUTION object 
1215 stores a pointer to the METADATA object 1010. The 
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MANAGER pointer of the EXECUTION object 1215 stores 
a pointer to a MANAGER object 1240. 

The CONTEXT_COLJLECnON structure of the MAN- 
AGER object 1240 includes context objects 1200, 1205, and 

5 1210. The context object 1205 includes KEY_VALUE 
objects 1220, 1225, and 1230. As previously mentioned and 
as later described herein, application of the EXECUTE 
method of the EXECUTION object 1215 causes the execu- 
tion of the instructions in the SALARY_ACnON unit 

10 1005. In contrast to FIG. 10, execution of the insUiictions in 
the SALARY__ACnON unit 1005 results in the TEMPI 
and TEMP2 variables being set to the values stored in the 
VALUE_STORAGE structures of the KEY_VALUE 
objects 1220 and 1225. Furthermore, the return output from 

15 the SALARY_FUNCnON 1000 is stored back into the 
VALUE_STORAGE structure of the KEY_VALUE object 
1230. 

* SET_PARAM Method ' ^ 

FIG. 13 is a flow diagram illustrating the operation of the 

20 SET_PARAM method of an execution object according to 
one embodiment of the invention. The SET_PARAM 
method receives as input parameters: 1) the unique key for 
the parameter kind to be set; 2) the value to store for that 
parameter; 3) and optionally a context object (see block 

25 1300). From block 1300 control passes to block 1305. 

In block 1305, it is determined if strong type checking is 
enabled. If strong type checking is enabled, control passes to 
block 1310. Othenvise, control passes to block 1325. While 
one embodiment described in which strong type checking 

30 can be enabled, alternative embodiments do not support the 
enabling/disabling of strong type checking or do not support 
strong type chedcing at all. 

In block 1310, the underlying METADATA object for the 
EXECUTION object is determined, lb provide an example, 

35 the objects shown in FIG. 10 will be used. Particularly, 
assume the SETJARAM method of the EXECUTION 
object 1015 is being applied. Using the METADAIA^ 
OBJECT_J»TR structure of the EXECUTION object 1015, 
the METADAEAobject 1010 is identified. From block 1310, 

40 control passes to block 1315. 

As shown in block 1315, it is determined if the passed key 
is stored in the INPUTS or OUTPUTS structure of the 
identified METADATA object. To continue the above 
example, assume that: 1) "EMPLOYEE_NAME" is the 

45 passed key; and 2) "John Smith" is the passed value. With 
reference to FIG. 10, in block 1315 it would be determined 
if the passed key ("EMPLOYEE_NAME") is stored in 
either the INPUTS or OUTPUTS structures of the META- 
DATA object 1010. If so, control passes to block 1325. 

50 Otherwise, control passes to block 1320. While one embodi- 
ment is described in which both the INPUTS and OUTPUTS 
structures are searched, alternative emtxxliments search only 
one (e.g., the INPUTS sUiicnire). 

In block 1320, the appropriate aaion is taken and the flow 

55 diagram ends. Of course, any number of different actions 
could be taken in block 1320, including the setting of a flag 
to indicate an error and the passing of control on to block 
1325. 

In block 1325, it is determined if a context object was 
60 passed to the SET JARAM method. If so, control passes to 
block 1335 where the passed context object is selected as the 
current parameter area. Otherwise, control passes to block 
1330 where the EXECUTION object's PARAMS coUecUon 
is selected as the current parameter area. In the example of 
65 FIG. 10, block 1330 would result in the selection of the 
PARAMS structure of the EXECUTION object 1015. Con- 
trol passes from both of blocks 1330 and 1335 to block 1340. 



03/16/2004, EAST Version: 1.4.1 



us 6,3; 

17 

In block 1340, it is determined if a matching key value 
object is already stored in the current parameter area* In 
other words, it is determined if there is a KEY_VALUE 
object in the current parameter area which has stored in it's 
KEY_STORAGE structure the passed key. If so, control 
passes to block 1350 where the VALUE_STORAGE sUnc- 
Uirc of the identified KEY_VALUE object is overwritten 
with the passed vahie (in this example, overridden with 
"John Smith"). Otherwise, control passes to block 1345 
where a KEY_VALUE object is added to the current 
parameter area. The added KEY_VALUE object has stored 
in it's KEY_STORAGE and VALUE_STORAGE struc- 
mres the passed key and value, respectively. In this manner, 
the values to be used as the input parameters to the under- 
lying function can be set. 
GETJARAM Method 

FIG. 14 is a flow diagram illustrating the operation of the 
GET_PARAM method according to one embodiriieiit of the 
invention. The GET_PARAM method receives as input 
parameters: 1 the unique key of the parameter kind for which 
a value is desired; and 2) optionally a context object (see 
block 1400). From block 1400, control passes to 1405. 

In block 1405, it is determined if the current key is in the 
PARAMS structure of the EXECUTION object. If so, con- 
trol passes to block 1430 where the corresponding value is 
returned. Otherwise, control passes to block 1410. To per- 
form block 1405, the KEY_VALUE objects in the 
PARAMS structure are searched to see if they contain in 
their KEY_STORAGE structure the passed key. If so, in 
block 1430 the value contained in the VALUE_STORAG£ 
stnictiire of the located KEY_VALUE object is remraed. To 
provide an example, assume the key ''EMPLOYEE. 
NAME" from FIG. 10 is passed. In this case, ''John South'* 
from the KEY_VALUE object 1020 would be returned. 

In block 1410, it is determined if a context object was 
passed. If a context object was passed, control passes to 
block 1420. Otherwise, control passes to block 1415. 

In block 1420 it is determined if the passed key is stored 
in the passed context object. If so, control passes to block 
1430 where the associated vahie is returned. Otherwise, 
control passes to block 1415. To perform block 1420, the 
KEY_VALUE objects associated with the passed context 
object are searched to see if they contain in their KEY_ 
STORAGE structure the passed key. If so, in block 1430 the 
value contained in the VALUE_STORAGE structure of the 
located KEY_VALUE object is returned. To provide an 
example, assume the key "EMPLOYEE_NAME" and the 
context db}cc\ 1205 of FIG. 12 is passed. In this case, "John 
Smith" from the KEY_VALUE object 1220 would be 
returned. 

As shown in block 1415, it is determined if a MANAGER 
object was passed. If a MANAGER object was passed, 
control passes to block 1425. Otherwise, control passes to 
block 1440 where NULL is returned. 

In btock 1425, it is determined if the MANAGER_PTR 
structure of the EXECUTION object is set. If so, control 
passes to block 1435. Otherwise, control passes to block 
1440. Particularly, a given EXECUTION object may or may 
not be associated with a MANAGER object. If a given 
EXECUTION object is associated with a MANAGER 
object, the MANAGER_PTR strucUire of that EXECU- 
TION object will store a pointer to that MANAGER object. 
Otherwise, the MANAGER_PTR structure of that EXECU- 
TION object will store null. 

In block 1425, it is determined if the default context 
structure of the identified MANAGER object is set. If so, 
control passes to block 1435. Otherwise, control passes to 
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blodc 1440. To provide an example, the objects illustrated in 
FIG. 12 wai be used. In FIG. 12, the MANAGER_PTR 
structure of the EXECUTION object 1215 contains a pointer 
to the MANAGER object 1240. In addition, the 

5 DEFAULT__CONTEXT structure of the manager object 
1240 can store a pointer to one of the context objects in the 
context collection. 

In block 1435, it is determined if the passed key is stored 
in the default context object. If so, control again passes to 

10 block 1430 where the value from the default context is 
returned. Otherwise, control passes to block 1440. Block 
1435 is performed in a similar manner to block 1420. 

In block 1440, null is remmed to indicate that a value for 
the passed key is not currently associated with the EXECU- 

15 TION object or the passed context object. 

In summary, the PARAMS structure has priority over a 
passed context object, and a passed context object has 
priority over the defaiilt context (if any). As'such, the default 
context can be used to store global/shared parameter values, 

20 whereas the passed context objects can be used to store 
specific parameter values. Furthermore, it is understood that 
in one embodiment the steps of FIG. 14 are performed 
individually for each key. As a result, the values for different 
keys can be acquired from different contexts (PARAMS, a 

25 passed context, the default context). 

By way of example, assume that there are a number of 
contexts to be processed. Particularly, assume certain pro- 
cessing must be done for each of employees Jack and Jane. 
While certain information will be specific to Jack and Jane 

30 (e.g., name), assume that certain information is shared by 
Jack and Jane (e.g., they both work for department K). In the 
described embodiment, the global values (e.g., department 
K) can be stored in the default context of a manager object, 
while the inquiry specific values (e.g., information specific 

35 to Jack and Jane) can be stored in separate "inquiry ^ecific" 
context objects (e.g., in the context collection structure of 
the manager object. As described later herein, applying the 
EXECUTE method for a given inquiry, the manager object 
and the appropriate inquiry specific context object can be 

40 passed as input parameters to the EXECUTE method. 
Assuming the execution object's PARAMS structure is 
empty, the global values and inquiry specific values can be 
acquired as described above. In this manner, the default 
context provides a global context feature, while the other 

45 contexts in the context collection structure provide specific 
context capabilities. 

While one embodiment of the invention is described with 
reference to a particular priority structure, alternative 
embodiments of the invention can have a different priority 

50 scheme. Furthermore, while one embodiment allows for the 
selection from multiple contexts, alternative embodiments 
can provide more or less contexts to select from. For 
example, one embodiment of the invention provides for only 
the PARAMS structure. Furthermore, embodiments of the 

55 invention can implement the context objects to be hierar- 
chical using well known techniques. In other words, a 
context object can have a parent context object. In this case, 
if a key is not found in a given context object, the system 
would recursively work its way up the hierarchy looking for 

60 the key. 

In addition, while one embodiment is described in which 
the passed key is used to search through the various contexts 
provided (e.g., the PARAMS structure, the context objects), 
alternative embodiments of the invention also search keys 
6S for derivatives of the parameter kind class of the passed key 
when no match is found for the passed key. For example, 
with reference to FIG. 2A, assume that the passed key is the 
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NAME key for NAME class 220. In one embodiment, 
assuming not match if found in the process, the searching 
described above with reference to FIG. 14 would be per- 
formed for each of the provided contexts. As a result of 
finding not match, a derivative of the parameter kind class 
NAME would be selected and the search would again be 
performed. Thus, the BEST.JJAME key from FIG. 2A 
could be selected and the contexts would be searched. 
Assuming that multiple matches are found in a context, a 
technique is used to select one (e.g., the first one found is 
chosen). 

While one embodiment is described in which each of the 
contexts is searched before moving on to derivatives, alter- 
native embodiments also search for derivative before mov- 
ing on to the next context. For example, the PARAMS 
structure would be searched for the passed key, as well as 
derivatives parameter kind classes thereof, before moving 
on to a passed context object and/or default context. 

In order to locate derivatives of a parameter kind class, the 
CLASS-PARENT_LABEL method and object tracking 
structure(s) can be used. Particularly, the CLASS- 
PARENT_LABEL method from the passed key is applied 
to identify the class label. This class label is then applied to 
the class hierarchy structure of the exemplary object track- 
ing structure to identify the class labels for the derivative 
classes. Using the derivative class label(s), the keys/class 
names for the derivative parameter kind classes can be 
determined from the class object placed in the instances 
tracking structure during class initialization. As previously 
described, alternative embodiments of the invention can use 
other mechanisms for tracking objects in the integration 
layer. Of course, embodiments of the invention which use 
different mechanisms for tracking objects in the integration 
layer would use their mechanism(s) accordii^y to identify 
derivative parameter kind classes. 
NEWJUSINESS Rule Method 

no. 15 is a flow diagram illustrating the operation of the 
NEW_EXECUnON method according to one embodiment 
of the invention. As previoiisly described, the operation of 
the NEW_EXECUTION method causes the creation of an 
execution object. The NEW_EXECUTION method 
receives as input parameters: 1) the name assigned a META- 
DATA object; 2) optionally a value identifying one or more 
CLASS_LABELs according to the CLASS-PARENT_ 
LABEL method; and 3) optionally a context object (see 
block 1500). Control passes from block 1500 to block 1505. 

FIG. 15 actually illustrates two separate flows. In 
particular, one embodiment of the invention provides a 
NEW_EXECUTION routine outside of a manger object 
and a NEW_EXECUTION method inside a MANAGER 
object. As such, FIG. 15 contains dashed lines between 
blocks 1520/1525 and block 1530. The NEW_ 
EXECUTION routine that resides outside a manager object 
ends at block 1520 or block 1525. In contrast, the NEW_ 
EXECUTION method within a manager object continues on 
to perform blocks 1530 through 1545. 

In block 1505, an execution object is instantiated and 
control passes to block 1510. In block 1510, metadata type 
objects in the integration layer are identified and control 
passes to block 1515. Block 1510 can be performed using a 
variety of different methods. For example, instances of the 
METADATA class (and derivatives thereof) can be stored in 
index structures. In an alternative embodiment, the object 
tracking structures previously described with reference to 
FIGS. 6A-8 are used. In particular, the label associated with 
the METADATA class can be found in the class hierarchy 
illustrated in FIG. 7. From the class hierarchy, the labels 
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assigned the derivatives of the METADATA class (if any) 
can be identified. The identified labels can then be used to 
access the instance tracking structure illustrated in FIG. 8 to 
identify instances of the METADATA class (and derivatives 

5 thereof). Furthermore, the optionally passed CLASS_ 
LABEL can be used to store the class label of a particular 
class to be used. When a CLASS_LABEL is passed, only 
the class with that class label (and derivatives thereof) are 
located in the instances tracking stmcture of FIG, 8. 

10 As shown in block 1515, it is determined if one of the 
METADATA objects identified in block 1510 matches the 
passed name. Block 1515 is performed by comparing the 
passed name to the value stored in the NAME structure of 
the METADATA type objects identified in block 1510. If a 

IS match is found, control passes to block 1525 where a pointer 
to the matching METADATA object is stored in the 
METADATA_OBJECT_PTR structure of the newly 
instantiated EXECUTION object (the EXECUTION object 
instantiated in block 1505). Otherwise, control passes to 

20 block 1520 where the METADArA^OBJECT_PTR of the 
newly instantiated EXECUTION object is set to null. 

During operation of the NEW_EXECUTION method 
within a MANAGER object, control passes from both of 
blocks 1520 and 1525 to block 1530. 

25 In block 1530, a pointer to the MANAGER object is 
stored in the MANAGER__PTR structure of the newly 
instantiated EXECUTION object. In this manner, the 
EXECUTION object is associated with the MANAGER 
object as illustrated in FIG. IB. From block 1530, control 

30 passes to block 1532. 

In block 1532, the newly instantiated EXECUTION 
object is added to the EXECUTION_COLLECnON of the 
MANAGER object. Cbntrol passes from block 1532 to 
block 1535. 

35 In block 1535, it is determined if a context object was 
passed. If so, control passes to block 1540 where the newly 
instantiated EXECUTION object is added to the passed 
context object. Otherwise, control passes to block 1545 
where the newly instantiated EXECUTION object is added 

40 to the default context object in the MANAGER object if one 
is identified by the DEFAULT_C0NT1EXT structure of that 
MANAGER object. 
FIND_^y^NAME Method 
FIG. 16 is a flow diagram illustrating the operation of the 

45 FIND_^y_NAME method according to one embodiment of 
the invention. The name assigned a METADATA object (and 
therefore assigned one or more execution objects) is passed 
as an input to the FIND_^y_NAME method. As previously 
described the FIND_^y_NAME method returns an execu- 

50 tion object associated with the METADATA object having 
the passed name. In addition to the name, the FIND_^y_ 
NAME method can have the following optional inputs: 1) a 
class label; and 2) a context object (see block 1600). Control 
passes from block 1600 to block 1605. 

55 In block 1605 it is determined if a context object is passed. 
If so, control passes to block 1610. Otherwise, control passes 
to block 1615. 

In block 1610, the passed context object is selected as the 
current context and control passes to block 1625. 

60 In block 1615, it is determined if the DEFAULT_ 
CONTEXT structure of the MANAGER object is set. If so, 
control passes to block 1620. Otherwise, control passes to 
blodc 1630. 

In block 1620, the default context object is selected as the 
65 current context and control passes to block 1625. 

In block 1625, the current context is searched for the 
passed name and control passes to block 1635. In other 
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words, the system attempts to detenniae if an executtOD of the inveation, the ioput(s) ''needed" for the execution 

objea matching the passed name is contained in the current object's underiying function are all inputs (regardless of 

context whether they are optional). In such an embodiment, the key 

In block 1(530, the EXECUTION^COLLECnON of the for every input to a function is stored in the INPUTS 

MANAGER object is searched for the passed name and 5 structure of the metadata object, and the inputs needed 

control passes to block 1635. includes the parameter for each key in the INPUTS struc- 

If a matching execution object is found, control passes ture. In an alternative embodiment, the input(s) "needed" 

from block 1635 to block 1645 where that execution object include those that are required, not those that are optional. In 

is returned. Otherwise, control passes from block 1635 to particular, in one such embodiment, data is stored as part of 

block 1640. 10 the INPUTS structure to indicate which (if any) of the 

In block 1640, the NEW_EXECUnON method of the parameters are optional. Parameters which are marked as 
MANAGER object is applied with the same parameters used optional are not considered "needed" as defined with refer- 
in block 1600. As a result, a new execution object is ence to block 1705. 

instantiated. From block 1640 control again passes to block In block 1715, the GET^PARAM method is applied for 

1645. 15 the current key and control passes to block 1720. As 

FIND_^y^NEED Method previously described, the GET_PARAM method returns a 

FIG. 17 is a flow diagram illustrating the operation of the value if the execution object has a value associated with the 

FIND^y_NEED niethbd according to one embodiment of current key (or in certain embodiments,"* a value associated 

the invention. As previously described, the FINT)^^_ with a derivative parameter kind class if not match is found 

NEED method is part of the MANAGER class. One of the 20 for the cunent key). Otherwise, the GET_PARAM method 

input parameters to the FIND_^_NEED method is a returns null. 

NEED_COLLECnON structure. The keys assigned the In block 1720, it is determined if a value was returned. If 

parameter kinds for which values are desired are stored in a so, control passes to block 1725. Otherwise, null was 

NEED_COLLECTION. Application of the FIND_^_ returned and control passes to block 1730. 

NEED method returns a set of EXECUTION objects that 25 In block 1725, the current key is added to the passed 

can be used to identify values for the needs. Particularly, the NEED collection and control passes to block 1730. In this 

EXECUTION objects in the returned set of EXECUTION manner, keys without associated values in the passed execu- 

objects have underlying functions with output parameters tion object are added to the NEED collection, 

matching the keys in the NEED_COLLECriON. As shown in block 1730, it is determined if the last key 

By way of example, the objects of FIG. 10 will be used. 30 has been processed. If not, control passes back to block 

With reference to FIG. 10, assume that the NEED_ 1710. Otherwise, control is passed to block 1735. 

COLLECTION contains the unique key "YEARLY_ In bk>ck 1735, a SATISFY^RELAnONSHIP routine is 

SALARY." As previously described, since the output param- invoked and control passes to block 1740. Invoking the 

eter TEMP3 of the SALARY_FUNCnON 1000 has been SAnSFY_JlELAnONSHIP routine generates an execution 

assigned the unique key "YEARLY_SAIARY,'' the unique 35 path of EXECUTION objects. 

key YEARLY_SALARY is stored in the OUTPUTS struc- There are a number of different ways to implement the 

ture of the METADATAobject 1010. As a result, application SAnSFY_JlELAnONSHIP routine. For example, in one 

of the FIND_jy-_NEED method would identify the under- embodiment of the invention, the SATISFY_ 

lying function for the METADATAobject 1010 provides an RELATIONSHIP routine is actually code contained in the 

output parameter matching the unique key contained in the 40 FIND^y_NE£D method. In an alternative embodiment, 

NEED_COLLECnON, and therefore return an execution the SAnSFY_RELAnONSHIP routine has been removed 

object associated with the MEXXDATA object 1010. from the nND_^yr_NEED method and placed in a separate 

The FIND_jy_NEED method additionally has the fol- locatk)n. For example, the concept of relationship objects 

lowing optional inputs: 1) an execution object; and 2) a later described herein can be used for this purpose. In one 

HAVE structure (e.g., a context object containing param- 45 embodiment of the invention, a relationship object is formed 

eters for which there are currently values assigned). From for storing a method to implement the SATISFY_ 

block 1700 control passes to block 1705. RELATIONSHIP routine. The operation of the SATISFY^ 

In block 1705, it is determined if an execution object is RELATIONSHIP routine will be further described herein 

passed. If so, control passes to block 1710. Otherwise, with reference to FIG. 18. 

control passes to block 1735. 50 As shown in block 1740, an execution path is returned. 

With reference to block 1710, blocks 1710-1730 in FIG. SAnSFY^RELAHONSHIP Routine 

17 are performed for each input needed for the execution FIGS. 18A-B are a flow diagram illustrating the operation 

object's underlying function. By way of example, the of the SAnSi^_RELAnONSHIP routine according to one 

objects of FIG. 10 will be used. Particularly, the EXECU- embodiment of the invention. The SATISFY^. 

TION object 1015 identifies the METADATAobject 1010. S5 RELATIONSHIP routine attempts to return an execution 

The METADATA object 1010 is associated with the under- path whose underlying functions will result in providing the 

lying SALARY_FUNCTION 1000. The SALARY^ output parameter kinds assigned the keys contained in the 

FUNCTION 1000 requires the input parameter kinds passed NEED_COLLECTION. The SATISFY^ 

assigned the unique keys "EMPLOYEE_NAME" and RELATIONSHIP routine is called with the same inputs as 

"EMPLOYEE_NUMBER." As a result, the METADATA 60 the FIND^^y^NEED method (see block 1800). From block 

object 1010 has stored in it's INPUTS structure the keys 1800, control passes to block 1810. 

"EMPLOYEE_NAME" and "EMPLOYEE_JWMBER." In block 1810, a consideration set that includes the 

Thus, blocks 1710-1730 of FIG. 17 are performed for both METADATA objects that have one or more of the needs in 

the unique keys "EMPLOYEE__NAME" and theirOUTPUTSsiructureiscreated.By way of example, the 

"EMPLOYEE_NUMBER." 65 objects of FIG. 10 will be used. Assume that the key 

For certain functions, certain inputs will be required '^EMPLOYEE.J^AME" is contained within the passed 

inputs, while other ate optional inputs. In one embodiment NEED_COLIJECTION. Since the OUTPUTS structure of 
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the METADATA object 1010 contains the "EMPLOYEE^ 
NAME- key, the METADATA object 1010 would be added 
to the consideration set In one embodiment, the previously 
described manners of identifying METADATA type objects 
(and derivatives thereof) are used (e.g., a CLASS_Xj\BEL 
parameter could optionally be passed). From the identified 
metadata type objects, metadata type objects having one or 
more needs in their OUTPUTS structure are selected. From 
block 1810, control passes to block 1815. 

In this manner, the exposed metadata in the METADATA 
objects (the unique keys contained in the outputs stmcture) 
are used to identify underlying functions in the integration 
layer that provide as output parameters those parameter keys 
identified in the NEED_COLLECnON. In other words, the 
exposed metadata in the METADATA objects allows for a 
search for the underlying functions whose output(s) will 
satisfy a particular nccd(s) of interest. 

In^block 1815,"it is determined' how many" METADATA 
objects are in the consideration set. If the consideration set 
is empty, control passes to blodc 1820. However, if the 
consideration set is not empty, control passes block 1822. 

In block 1820, there are no metadata objects with under- 
lying functions that will provide the desired output param- 
eter kind. As such, in block 1820 null is reUiraed. 

In bbck 1822, one or more solution sets of METADATA 
object(s) &om the consideration set are determined and 
control passes to block 1825. In particular, the system 
determines from the consideration set one or more solution 
sets of metadata objects whose underlying functions will 
collectively provide values for the needs in the passed 
NEED_COLLECnON structure. 

Many different techniques can be used for determining the 
solution sets. For example, in one embodiment block 1822 
is performed by selecting the first metadata object(s) in the 
consideration set that satisfy the needs. In another alternative 
embodiment of the invention, block 1822 is performed by 
first extracting into a solution set the metadata objects from 
the consideration set that must be used. In particular, if only 
one of the METADATA object's underlying function pro- 
vides one or more of the needs in the NEED_ 
CX)LLECnON, then that metadata object must be used. 
Next, it is determined how many metadata objects are left in 
the consideration set. If no MEX\DATA objects are left in 
the consideration set (all of the metadata object(s) in the 
consideration set must be used), then only one solution set 
exists and control passes to block 1830. However, if there 
are still muhiple metadata objects in the consideration set 
(i.6., multiple ones of the underlying functions can be used 
to satisfy the same need identified in the NEED_ 
COLLECTION), there are multiple execution paths (e.g., 
see FIG. 21) and multiple solution sets are possible 
(however, certain embodiments only determine one). Again, 
a number of different techniques can be used to form 
solution sets from the metadata objects left in the consider- 
ation set after necessary metadata objects are removed (note, 
each solution set will inchide the metadata objects that causi 
be used). For example, the first metadata objects that satisfy 
the needs could be selected. As another example, all of the 
solution sets are determined (e.g., certain embodiments 
index all the output parameters, and use the indexes to 
determine the solution sets). As another example, a costing 
technique could be used. 

In block 1825, one of the solution set(s) is selected and 
control passes to block 1830. Again, any number of tech- 
niques could be used to perform this selection. For example, 
in one embodiment blodc 1825 is performed by selecting the 
first solution set In an another embodiment of the invention, 
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the well known technique of costing is used to select from 
the solution sets. When using costing, the solution set whose 
metadata object(s)' underlying functions would cost the 
least to produce the needs identified by the NEED_ 

5 COLLECTION is selected. The optional HAVE structure 
can be used during this costing process to determine which 
of the functions for the metadata objects in a solution set will 
be cheapest. Particularly, the HAVE structure identifies the 
values that are akeady established. As such, if two metadata 

10 objects will satisfy a need, but the first requires an input that 
is not in the HAVE structure and the second does not, then 
the second will likely cost less than the first. 

As shown in block 1830, the NEW__EXECUTION 
method for the METADATA object(s) in the selected solu- 

15 tion set is applied. For example, if the above consideration/ 
solution set technique is used, the NEWJXECUTION 
method is applied for each of the metadata objcct(s) in the 
solution set. As a result, block 1830 provides an execution 
object for each metadata object in the solution set. Control 

20 passes from block 1830 to block 1835. With reference to the 
example of FIG. 21, assume that function E was selected. As 
such, an execution object for the metadata object identifying 
the fimction E would be created. 
In block 1835, a level object is created and added to the 

25 beginning position of ordered execution in a temporary 
execution path collection. In other words, by block 1835 the 
functions for one level of an execution path have been 
identified and execution objects have been formed for each 
function. These execution objects are then placed in a level 

30 object which is placed in the ordered collection of a tem- 
porary execution path. With reference to the above example 
where function £ of FIG. 21 was selected, a level N object 
would be created for the execution object from block 1830. 
As shown in block 1840, it is determined if all of the 

35 needed inputs to the functions represented by the level 
object of block 1835 are available (in the HAVE structure). 
If so, control passes to block 1867 because an end of an 
execution path has been reached. Otherwise, control passes 
to block 1845. With reference to the above example where 

40 function E of FIG. 21 was selected, control would pass to 
block 1845. 

In an alternative embodiment, an optimization is made in 
which a block is performed between blocks 1835 and 1840. 
In particular, it is determined, for each execution object on 

45 the current level, whether all of the inputs for that execution 
object's underlying function are in the HAVE structure. In 
other words, it is determined whether an execution object's 
underlying function could have been executed on the early 
level. For each such execution object, the output(s) of that 

50 execution object are added to the HAVE structure. 

In block 1845, a need collection is created for the needed 
inputs and control passes to block 1850. As shown in block 
1850, the satisfy relationship routine is invoked and control 
passes to block 1855. As such, a reiterative process is begun 

55 to work up the execution path through the outputs of the 
function. With reference to the example of FIG. 21, the 
needs for E will identify the functions A, D and F, 

As shown in block 1855, it is determined if all of the 
solution sets have all been processed. If not, control passes 

60 to block 1865 from which control is passed back to block 
1825 for selection of another solution set. To continue the 
above example, assume that the consideration set A, D, and 
F is being processed. The consideration set A, D, and F 
results in two solution sets: (A, D) and (A, F). In addition, 

65 on the initial pass through block 1825, assume that the 
solution set (A, D) was selected. As a result, when block 
1855 is reached, the solution set (A, F) will not yet have been 



03/16/2004, EAST Version: 1.4.1 



us 6,338,069 Bl 

25 26 

processed and control will pass back to block 1823 where through C remains). This return to block 1825 will result in 

solution set (A, F) will be selected. Whereas, if it was the solution set (C) being selected (instead of the already 

determined that all the solution sets have been processed, processed solution set that contained B). Processing for the 

control passes to block 1860 where a return is performed. It solution set (C) will reach block 1850 where a fourth 

should be noted that one embodiment only completes one 5 recursive call is made based on the input needs of function 

solution set, and therefore does not perform blocks 1855 and C. On this fourth recursive call, the solution set containing 

1865 when an execution path has been established (e.g., A will again be determined and selected. Processing for A 

control passes from block 1850 to block 1860). will again reach block 1870 where this second execution 

As shown in block 1867, the end of an execution path has path is costed. Assuming this second execution path is not 

been reached and duplicate execution objects are removed. lO cheaper than the first, block 1885 is reached and processing 

From block 1867, control passes to block 1870. This concept returns to block 1855 of the second recursive call. This time, 

is further described later herein. While one embodiment is all solution sets have been processed (both B and C of the 

described in which duplicates are removed, alternative left side tree) for the second recursive call and processing 

embodiments need not remove duplicates. returns to block 1855 of the first recursive call. Processing 

In block 1870, the path' is costed and control passes to 15 continues as such, 

block 1875. For example, when function A of FIG. 21 is While one embodiment is described in which each execu- 

rcached. Any number of different costing mechanisms could tion path is processed to completion, alternative cmbodi- 

be used. In one embodiment of the invention,*each "metadata ments of the invention attempt to improve performance by 

object has stored therein a value indicating the cost of the restricting execution path processing. For example, one such 

metadata object. The values from each of the metadata 20 alternative embodiment calculates costing on the fly and 

objects in the execution path are summed to determine the terminates processing of an execution path that exceeds a 

cost of the execution path. In alternative embodiments of the previous best execution path. As another example, altema- 

invention, other costing mechanisms can be used (e.g., a tive embodiments can restrict the number of recursive levels 

method could be used to determine cost). processed (e.g., execution paths over a certain number of 

As shown in block 1875, it is determined if the current 25 levels are aborted), 

execution path is cheaper than a previously selected execu- In addition, while one embodiment is described in which 

tion path (if any). If the current execution path is cheaper, costing is used, alternative embodiments do not use costing, 

control passes to block 1880. Otherwise, control passes to For example, one such alternative embodiment just pidcs the 

block 1890. first metadata objects in block 1825 to create a first execu- 

In block 1880, the current execution path is stored as the 30 tion path, and never determines other execution paths (e.g., 

selected execution path and control passes to block 1885 does not perform blocks 1855, 1865, 1875, 1890). 

where a return is performed. In this manner, the cheapest of The FIND_^_NEED_AND_EXECUTE method is the 

the execution paths is selected. same as the FIND_^_NEED method, with the exception 

As shown in block 1890, a previously selected execution that the FIND_^_J»JEED_j\ND_EXECUTE causes the 

path is cheaper and the current temporary execution path is 35 EXECUTE methods on the execution path to be applied, 

discarded as a return is performed. .^>pUcation of the EXECUTE methods on the execution 

y/ith reference to FIG. 21, the flow of FIG. 18 will now path results in values being provided for the keys contained 

be described. Assume that the initial consideration set in the N£ED_OOLLECTION. 

includes function E, and that E is selected in block 1825. EXECUTE Method 

Processing for E will reach block 1850 where a recursive 40 FIG. 19 is a flow diagram illustrating the operation of the 

call is made based on the input needs of function E (Best EXECUTE method according to one embodiment of the 

Name and Spouse's Name). On this first recursive call, the invention. As previously described, a given EXECUTION is 

cotisideration set will include A, D, and F; and the solution associated with a METADATA object, which in turn is 

sets will be (A, D) and (A, F). Assume that solution set (A, associated with an action unit, which in turn is associated 

D) is selected (in block 1825). Processing for (A, D) will 45 with a function being tracked by the integration layer, 

reach block 1850 where a recursive call is made based on the Application of the EXECUTE method from an execution 

input needs of function D (the input of function A is object causes the execution of the underlying function using 

available in the HAVE structure). On this second recursive the values associated with that EXECUTION object, as well 

call, the consideration set will include B and C; and the as causes the associating of the outputs from the underlying 

solution sets will be (B) and (C). Assume that function B is 50 fiinction with that EXECUTION object. It is worthwhile to 

selected. Processing for B vvill reach block 1850 where a point out that the phrase "the values associated with an 

recursive call is made based on the input needs of function execution object" can refer to either the KEY_VALUE 

B (Id). On this third recursive call, the consideration set will objects stored in the PARAMS structure of that EXECU- 

include function A, and thus there is one solution set. Since TION object or a context object in a MANAGER object. In 

the inputs from the solution set of A are available in the 55 addition, certain embodiments of the invention optionally 

HAVE structure, processing for A wdll reach block 1870 allow a context object be passed as an input parameter to the 

where duplicates are removed. Particularly, the execution EXECUTE method. In this situation, one or more of the 

path is now A to B, B to D, and both A and D to E. Since KEY_VALUE objects in the passed context object may be 

function A is duplicated, one is removed to create the used. 

execution path A to B, B to D, and D to E. This execution 60 As described later herein, there are times when values for 

path is then costed. In addition, since this is the first the required inputs to the underlying functions are not yet 

execution path, this path will be stored as the selected associated with the EXECUTION object (or contained in the 

execution path and block 1885 will be reached. passed context object, if present). In this situation, the 

As a result of the return in block 1885, processing will previously described satisfy-relationship routine can be used 

return to block 1855 of the second recursive call. On this 65 in a recursive fashion to generate EXECUTION objects 

call, control will pass through block 1865 to bbck 1825 whose underlying functions are applied to provide the 
because the solution set (Q remains (the path from D to A missing values. 
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The inputs to the EXECUTE method are optionally: 1) a 
N4ANAGER object; and 2) a context object (see block 
1900). Control passes from block 1900 to block 1905. 

With reference to block 1905, blocks 1910-1930 in FIG. 
19 are performed for each input needed for the exccutioo 
object's underlying function. Block 1905 can be performed 
in a similar manner to block 1710. Control passes from 
block 1910 to block 1915. 

As shown in block 1910, an attempt is made to associate 
a value with the key currently being processed. From block 
1910, control passes to block 1915. 

In one embodiment, block 1910 is performed by applying 
the GET_PARAM method for the current key and then 
applying the SET_PARAM method for the current key with 
the value from the GET_PARAM method In an alternative 
embodiment, block 1910 is performed with a modified 
version of the flow shown in FIG. 14. Particularly, the 
SET_PARAM method need not be applied after the GET_ 
PARAM if the value is already stored in the PARAMS 
structure. As such, this modified version of the flow in FIG. 
14 does not apply the SET_PARAM method if the matching 
KEY_VALUE object is found in the PARAMS structure. In 
addition, as similarly described with reference to the GET_ 
PARAM method, certain embodiments of the invention may 
allow the searching for matches to be performed using 
derivatives of the parameter kind class assigned the passed 
key. Furthermore, certain embodiments of the invention may 
provide searching for matches using derivatives of the 
parameter kind class for only one of the GET_JPARAM 
method and the technique used for block 1910. 

In the embodiment previously described, the PARAMS 
structure has priority over a passed context object, and a 
passed context object has priority over the default context (if 
any). As such, the default context can be used to store 
global/shared parameter values, whereas the passed context 
objects can be used to store specific parameter values. 
Furthenmore, it is understood that in one embodiment that 
blocks 1910-1930 are performed individually for each key. 
As a result, the values for different keys can be acquired 
from different contexts (PARAMS, a passed context, the 
default context). 

By way of example, assume that there are a number of 
contexts to be processed. Particularly, assume certain pro- 
cessing must be done for eadi of employees Jack and Jane. 
While certain information will be specific to Jack and Jane 
(e.g., name), assume that certain information is shared by 
Jack and Jane (e.g., they both work for department K). In the 
described embodiment, the global values (e.g., department 
K) can be stored in the default context of a manager object, 
while the inquiry specific values (e.g., information specific 
to Jack and Jane) can be stored in separate "inquiry specific'* 
context objects (e.g., in the context collection strucmre of 
the manager object. When applying the EXECUTE method 
for a given inquiry, the manager object and the appropriate 
inquiry specific context object can be passed as input 
parameters to the EXECUTE method. Assuming the execu- 
tion object's PARAMS structure is empty, the global values 
and inquiry specific values will be associated with the 
execution object as described above. In this manner, the 
default context provides a global context feature, while the 
other contexts in the context collection structure provide 
specific context capabilities. 

While one embodiment of the invention is described with 
reference to a particular priority structure, alternative 
embodiments of the invention can have a different priority 
scheme. Furthermore, while one embodiment allows for the 
selection from multiple contexts, alternative embodiments 



8,069 Bl 

28 

can provide more or less contexts to select from. For 
example, one embodiment of the invention provides for only 
the PARAMS structure. In addition, while certain embodi- 
ments allow values for different keys to be provided from 

5 different contexts, alternative embodiments select one con- 
text from which all values must come. Furthermore, embodi- 
ments of the invention can implement the context objects to 
be hierarchical using well known techniques. In other words, 
a context object can have a parent context object. In this 

10 case, if a key is not found in a given context object, the 
system would recursively work its way up the hierarchy 
looking for the key. 

As shown in block 1915, it is determined if a value was 
associated with the current key. If so, control passes to block 

15 1930. Otherwise, control passes to block 1925. 

In block 1925, since there is no value associated with the 
key, a need has been identified (i.e., one of the required input 
parameters for the underlyiiig function has no value). As 
such, in block 1925, the current key is stored in a NEED_ 

20 COLLECTION. As previously described, the NEED_ 
COLLECTION is used by the SAnSFY_RELAnONSHIP 
routine to locate other execution objects with underlying 
functions that can provide vahies for missing input param- 
eters. The manner in which this is performed during the 

25 EXECUTE method is further described later herein. Control 
passes from block 1925 to block 1930. 

In block 1930, it is determined if all of the keys from the 
INPUTS structure of the metadata object have been pro- 
cessed. If not, control passes back to block 1905. Otherwise, 

30 control passes to block 1935. 

In block 1935, it is determined if the NE£D_ 
COLLECTION is empty. If the NEED_COLLECnON is 
empty, then there are values established for each of the 
required input parameters to the underlying function and 

35 control passes to bbck 1945. However, if there are keys in 
the NEED_COLLECnON, control passes to block 1940. 

In block 1940, the PARAMETER^SAITSFY method 
from the EXECUTION object is applied for the NEED_ 
COLLECTION. The PARAMETER_SAnSFY method 

40 will be described later herein with reference to FIG. 20. 
However, it is worthwhile to note that the PARAMETER^ 
SATISFY method is designed to use the basic techniques of 
the SATISFY_RELAnONSHlP routine to locate and 
execute other functions (via EXECUTION objects and 

45 METADATA objects) that will provide the missing input 
parameter values. From block 1940, control passes to block 
1945. 

As shown in block 1945, the action method from the 
metadata object identified by the execution object is caused 
50 to be executed using the established parameter values. 

Thus, the invention provides for an execution framework 
for functions that allows execution plans to be determined 
and performed. 

PARAMETER_SAnSFY Method 

55 FIG. 20 is a block diagram illustrating the 
PARAMETER_SAT1SFY method according to one 
embodiment of the invention. The PARAMETER_ 
SAnSFY method receives the same inputs as the F1ND_ 
^r_NEED method previously described (see block 1700). 

60 From block 2000, control passes to block 2005. 

In block 2005, the SAHSFY^RELAnONSHlP routine is 
invoked and control passes to block 2010. As previously 
described, invoking the SAnSFY__RELAnONSHIP rou- 
tine will attempt to return an execution path for the NEED 

65 COLLECTION parameter. 

In block 2010, the execution path is performed and 
control passes to block 2015. In one embodiment, the 
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execute methods of the execution objects in the level objects 
of the EXECUnON_PArH_COLLECnON structure are 
applied in level order. 

It should be noted that application of each EXECUTE 
method requires the operations illustrated in FIG. 19 to be 
performed. It should be understood that application of one or 
more of these EXECUTE methods could also result in a 
determination that the values for one or more required inputs 
of an imderlying function is missing. In other words, this 
operation can be recursive in nature. 

According to the embodiment shown io FIG. 20, for each 
key in the NEED^COLLECTIGN (sec block 2015) it is 
verified that a value was acquired. In particular, block 2020 
determines if a value was returned. If a value was not 
returned, control passes to block 2030 in which a flag is set 
for debugging purposes. However, if a value was returned, 
then the SET_PARAM method is applied with the returned 
value to associate the value with the EXECUTION object. 
While one embodiment is described in which verification 
that a value was returned for each key in the need collection 
is performed, alternative embodiments can avoid this veri- 
fication and/or provide for this verification in other areas. 

In this manner, values for any of the missing input 
parameters to the underlying function are located as part of 
applying the EXECUTE method from the EXECUTION 
object. 

Relationship Objects 

In one embodiment, the integration layer also includes 
two types of objects^ base objects and relationship objects. 
The base objects describe the disparate integration sources 
A-i. The relationship objects describe relationships between 
the base objects, as well as relationships between the rela- 
tionship objects themselves. 

Specifically, the common concept of encapsulation in 
object technology is to place data with its' associated 
methods together in a single object. In contrast, the integra- 
tion layer is developed such that those methods that express 
a relationship (referred to herein as "relationship methods") 
are placed in separate objects — the relationship objects. In 
this manner, a higher degree of encapsulation is provided. 
While relationship methcKls within relationship objects are 
similar to methods commonly found in object technology in 
that they can be applied to the objects that contain them, 
relationship methods within relationship objects are differ- 
ent in that they often are applied to other objects, including 
base objects and other relationship objects. For a further 
description of relationship objects, see '*A Method and 
Apparatus for Providing Relationship Objects and Various 
Features to Relationship and Other Objects," filed Sep. 30, 
1998, by Bhalchandra Gbatate, which is herein incoiporated 
by reference. 

As previously indicated, in one embodiment of the 
invention, relationship object(s) are used to provide for one 
or more SATISFY^RELATIONSHIP routines. In this 
manner, different types of satisfy relationship routines can 
be provided and selected from using the relationship object 
techniques. 

Alternative Embodiments 

While the invention has been described in terms of several 
embodiments, those skilled in the art will recognize that the 
invention is not limited to the embodiments described. The 
method and apparatus of the invention can be practiced with 
modification and alteration within the spirit and scope of the 65 
appended claims. The description is thus to be regarded as 
illustrative instead of limiting on the invention. 
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What is claimed is: 

1. A machine readable medium having stored thereon: 

a function requiring a set of one or more input parameters; 
a first object iochiding, 
a first structure storing a key for each of said set of input 

parameters, and 
an action method, which when applied by a processor, 
causes that processor to invoke an action unit; and 
a second object including, 

a first structure to store data for identifying, for each of 
said set of input parameters, the corresponding key 
and a value for that input parameter, 
a second structure identifying said first object, and 
an execute method, which when applied by a processor, 
causes that processor to apply said action method; 
said action unit including instructions, which when 
executed by a processor, cause that processor to, • 
access said values, and 

invoke said function using said values as input param- 
eters. 

2. The machine readable medium of claim 1, wherein said 
function is contained within said action unit. 

3. The machine readable medium of claim 1, wherein said 
first structure in said second object has stored therein, for at 
least one of said set of input parameters, the corresponding 
key and a value for that input parameter. 

4. The machine readable medium of claim 1, wherein: 
the data in said first structure of said second object 

identifies a third object; and 
said third object includes a structure to store, for one or 
more of said set of input parameteis, the corresponding 
key and value for that input parameter. 

5. The machine readable medium of claim 1, wherein: 
the data in said first strucmre of said second object 

identifies a third object; and 
said third object includes, 

a first structure to store a plurality of context objects, 
each of said plurality of context objects to store, for 
one or more of said set of input parameters, the 
corresponding key and a value for that input 
parameter, and 

a second structure to store data identifying one of said 
plurality of context objects as a de&ult context 
object, 

6. The machine readable medium of claim 1, wherein: 
said fiinction provides a set of one or more output 

parameters; 

said first strucmre io said first object also storing a key for 
each of said set of output parameters. 

7. A machine readable medium having stored thereon: 

a function requiring a set of one or more input parameters; 
a first object inchiding, 

a first structure storing a key for each of said set of input 

parameters, and 
an action method, which when applied by a processor, 
causes that processor to invoke said function; and 
a second object including, 

a first sUTicture identifying a third object, 
a second structure identifying said first object, and 
an execute method, which when applied by a processor, 
causes that processor to apply said action method; 
and 

said third object including, 

a first structure to store a plurality of context objects, 
each of said plurality of context objects to store, for 
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one or more of said set of input parameteis, the 
corresponding key and a value for that input 
parameter, and 
a second structure to store data identifying one of said 
plurality of context objects as a default context 
object. 

8. The machine readable mediiun of claim 7 further 
having stored thereon: 

an action unit including said function as a method. 

9. The machine readable medium of claim 7 further 
having stored thereon: 

an action unit including instructions, which when 
executed by a processor, cause that processor to invoke 
said function; and 

wherein said action method, when applied, causes the 
execution of the instructions in said action unit. 

10. - The machine readable medium of claim 7 further • 
having stored thereon: 

an action unit including instructions, which when 
executed by a processor, cause that processor to, 
access values for one or more of said set of input 
parameters from a selected one of said plurality of 
context objects that is passed to said action unit, and 
invoke said function using said values as input param- 
eters; and 

wherein said action method, when applied, causes said 
function to be invoked through the instructions in said 
action unit 

11. The machine readable medium of claim 10, wherein: 
said second object also includes a first structure storing 

data identifying, for one or more of said set of input 
parameters, the corresponding key and a value for that 
input parameter; and 
said instructions of said action unit, when executed by a 
processor, also cause that processor to access values for 
one or more of said set of input parameters from said 
first structure. 

12. The machine readable medium of claim 11, wherein: 
said instructions of said action unit, when executed by a 

processor, also cause that processor to access values for 
one or more of said set of input parameters from said 
default context object. 

13. The machine readable medium of claim 11, wherein: 
said instructions of said action unit, when executed by a 

processor, also cause that processor to access vahies for 
one or more of said set of input parameters from said 
default context object. 

14. The machine readable medium of claim 7 fiirtber 
having stored thereon: 

said second object also includes a first structure to store 
data identifying, for one or more of said set of input 
parameters, the corresponding key and a value for that 
input parameter; and 
an action unit including instructions, which when 
executed by a processor, cause that processor to, 
access values for said set of input parameters from said 
first structure of said second object, a selected one of 
said plurality of context objects that is passed to said 
action unit, and said default context object, and 
invoke said function using said values as input param- 
eters. 

15. A machine readable medium having stored thereon: 
a plurality of functions for one or more applications^ each 

of said plurality of functions requiring one or more 
input parameters, the input parameters required by said 
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plurality of functions collectively defining a set of 
parameter kinds irrespective of data type, each param- 
eter kind in said set being assigned a unique key; 

a metadata object corresponding to each of said plurality 
5 of functions, each said metadata object storing data to 
locate the corresponding one of said plurality of 
functions, each said metadata object also storing the 
unique key for each input parameter required by the 
corresponding one of said plurality of functions; and 

each metadata object having one or more corresponding 
execution objects, each execution object including a 
structure storing data to identify a value for each input 
parameter of the one of said plurality of functions 
identified by the corresponding metadata object. 

16. The machine readable medium of claim 15, wherein 
each parameter of said plurality of functions is of one of a 
plurality of. data types each, supporting, a range, of .values, 
wherein different data is categorized irrespective of data 
type, and wherein each category of data defines one of the 
parameter kinds. 

17. The machine readable medium of claim 15 further 
having stored thereon: 

an action unit for each of said plurality of functions, each 
^ of said action units including instructions, which when 
executed by a processor, cause that processor to invoke 
the corresponding one of said plurality of functions; 
and 

wherein the data in each of said metadata objects for 
30 locating the corresponding one of said plurality of 
functions identifies the corresponding one of said 
action units; and 
wherein each of said metadata objects includes an action 
method, which when applied, causes the execution of 
35 the instructions in the corresponding one of said action 
units. 

18. The machine readable medium of claim 17, wherein: 
each execution object includes a method, which when 

applied, causes said action method of the correspond- 
40 ing metadata object to be applied for that business rule; 

each action method, when applied responsive to the 
method of an execution object, causes the instructions 
in the corresponding action unit to be executed for that 
business rule; and 

the instructions in each action unit, when applied respon- 
sive to an action method responsive to the method of an 
execution object, causes the values of that business rule 
to be accessed and said function of that action unit to 
be invoked with said values as input parameters. 

19. The machine readable medium of claim 15, wherein 
at least one of said execution objects stores the key and a 
corresponding value for at least one input parameter of the 
corresponding one of said plurality of functions. 

20. The machine readable medium of claim 15, wherein: 
at least one of said execution objects includes a structure 

identifying a manager object; and 
said manager object includes a structure to store the key 
and a corresponding value for at least on input param- 
eter of the one of said plurality of functions correspond- 
ing to the at least one of said execution objects. 

21. The machine readable medium of claim 15, wherein: 
at least one of said execution objects includes a structure 

identifying a manager object; and 
65 said manager object includes, 

a first structure to store a plurality of context objects, 
each of said plurality of context objects to store the 
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key and a ooriesponding value for one or more input 
parameters to at least certain of the plurality of 
functions, and 
a second structure to store data identifying one of said 
plurality of context objects as a default context 
object. 

22. The machine readable medium of claim 15, wherein: 
each of said plurality of functions provides one or more 

output parameters, the input and output parameters of 
said plurality of functions collectively defining said set 
of parameter kinds irrespective of data type; 
each said metadata object also storing the unique key for 
each input and output parameter of the corresponding 
one of said plurality of functions. 

23. A machine readable medium having stored thereon 
sequences of instructions, which when executed by a set of 

. one or more processors,, cause said set of one or more 
processors to perform the acts of: 

applying a first method from a first execution object, said 
first execution object identifying a first metadata object 
corresponding to a first function, said first function 
requiring one or more input parameters, said first 
metadata object storing data describing each input 
parameter of said first function, said first method caus- 
ing the acts of, 

accessing the data describing each input parameter of 

said first function from said first metadata object; 
attempting to match values associated with said first 

execution object to each input parameter of said first 

function as described by the data; and 
determining a value is missing for at least a first input 

parameter to said first function. 

24. The machine readable medium of claim 23, wherein 
said first method further causes the acts of: 

locating a second metadata object corresponding to a 
second function having one or more output parameters, 
said second metadata object storing data describing 
each output parameter of said second function; 

determining the missing first input parameter is an output 40 
parameter of said second function; and 

executing said second function to acquire the missing 
value. 

25. The machine readable medium of claim 24, wherein 
said first method further causes the act of: 

associating the acquired value with said first execution 
object; and 

executing said first function using the acquired value now 
associated with said first execution object as the first 
input parameter. 

26. The machine readable medium of claim 23, wherein 
said first method further causes the acts of: 

determining a set of metadata objects that each have 
stored therein data describing an output parameter that 
matches one or more of the missing input parameters, 
wherein each metadata object in said set corresponds to 

^ a different function having a set of one or more output 
parameters, each metadata object in said set storing 
data describing said set of output parameters for the 
corresponding function; and 

executing the functions corresponding to the set of meta- 
data objects to acquire said set of missing values; 

associating the acquired values with the first execution 
object; and executing said first function using the 65 
values associated with the first execution object as 
input parameters. 
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27. The machine readable medium of claim 23, wherein 
said attempting further includes: 

accessing a strucmre in said first execution object, said 
structure in said first execution object to store values 
for one or more said set of input parameters to said first 
function. 

28. The machine readable medium of claim 23, wherein 
said attempting further includes: 

accessing a structure in a manager object identified by a 
structure in said first execution object, said structure in 
said manager object identifying a default one of a 
plurality of context objects, each of said plurality of 
context objects to store values for one or more of the 
input parameters to said first function; and 

accessing said values from said default context object. 

29. The machine readable medium of claim 23, wherein 
said sequences of instructions, when executed, cause said set 
of processors to further, perform the. acts of: 

applying a first method from a second execution object, 
said second execution object also identifying said first 
metadata object, said first method of said second execu- 
tion object causing the acts of, 
accessing the data describing each input parameter of 

said first function from said first metadata object; 
attempting to match values associated with said second 
execution object to each input parameter of said first 
function as described by the data in said first meta- 
data object; and 
determining one or more values are missing for at least 
certain input parameters of said first function. 

30. A machine readable medium having stored thereon 
sequences of instructions, which when executed by a set of 
one or more processors, cause said set of one or more 
processors to perform the acts of: 

applying a first method from a first execution object, said 
first execution object identifying a first of a plurality of 
metadata objects, each of said plurality of metadata 
objects identifying a different function, each of said 
frinctions having input and output parameters, wherein 
one or more parameters for different functions are the 
same, the parameters for the different functions collec- 
tively defining a set of parameter kinds, each parameter 
kind in said set of parameter kinds being assigned a 
unique key, each of said plurality of metadata objects 
storing the unique keys assigned the input and output 
parameters of the function they identify, said first 
method causing the acts of, 

accessing the key for each input parameter stored in 

said first metadata object; 
attempting to match parameter values associated with 

said first execution abject to each of the accessed 

keys; and 

determining parameter values are missing for a set 
inchiding at least one of the accessed keys. 

31. The machine readable medium of claim 30, wherein 
each parameter of said functions is of one of a plurality of 
data types each supporting a raage of values, wherein 
different data is categorized irrespective of data type, and 
wherein each category of data defines one of the set of 
parameter kinds. 

32. The machine readable medium of claim 30, wherein 
said first method further causes the acts of: 

locating a set of one or more of said plurality of metadata 
objects that collectively store each of the set of keys; 
and 

executing the functions corresponding to the set of meta- 
data objects to acquire said set of missing parameter 
values as outputs of the functions; 
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associating the acquired parameter values with the first 
execution object; and 

executing the function identified by the first metadata 
object using the parameter values associated with the 
first, execution object as input parameters. 

33. The machine readable medium of claim 30, wherein 
said attempting further includes: 

accessing a sUoicture in said first execution object, said 
structure in said first execution object to store values 
for one or more said set of input parameters to the 
function identified by the first metadata object. 

34. The machine readable medium of claim 30, wherein 
said attempting further includes: 

accessing a structure in a manager object identified by a 
structure in said first execution object, said structure in 
said manager object identifying a default one of a 
plurality of context objects, eadi of said plurality of 

context.objects to store values, for one or more of the 

input parameters to said first fiinction; and 

accessing one or more of said values from said default 
context object. 

35. The machine readable medium of claim 30, wherein 
said sequences of instructions, when executed, cause said set 
of processors to further perform the acts of: 

applying a first method from a second execution object, 
said seoond execution object also identifying said first 
metadata object, said first method of said second execu- 
tion object causing the acts ot 
accessing the key for each input parameter stored in 

said first metadata object; 
attempting to match values associated with said second 

execution object to each of the accessed keys; and 
determining parameter values are missing for a set 

including at least one of the accessed keys. 

36. The machine readable medium of claim 30, wherein 
said attempting further includes: 

accessing from a first structure in said first execution 
object a value for a first input parameter to said function 
identified by said first metadata object; 

accessing, from a first of a set of context objects that was 
passed, a value for a second input parameter to said first 
function, said set of context objects being stored in a 
first structure of a manager object, each of said set of 
context objects to store values for one or more of the 
input parameters to said first function, said manager 
otyject identifying one of said set of context objects as 
a default context object; and 

accessing from said default context object a value for a 
third input parameter to said first function. 

37. A machine readable medium having stored thereon 
sequences of instructions, which when executed by a set of 
one or more processors, cause said set of one or more 
processors to perform the acts of: 

receiving a request to locate a function that provides a 

particular parameter kind as an output; 
locating a metadata object having stored therein data 
identifying said particular parameter kind, said meta- 
data object identifying a function and storing said data 
to indicate the particular parameter kind is an output 
parameter of said function; and 
providing an execution object that identifies said metadata 
object, wherein said execution object includes, 
structure to identify values for a set of one or more 

input parameters to said fimction, and 
a method, which when applied, causes said function to 
be invoked using the values identified by said struc- 
ture as input parameters. 
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38. The machine readable medium of claim 37, wherein: 
said fimction has a plurality of parameters, said metadata 

object stores data identifying each kind of said phirality 
of parameters. 

39. The machine readable medium of claim 38, wherein 
each parameter of said function is of one of a plurality of 
data types each supporting a range of values, wherein 
diJOferent data is categorized irrespective of data type, and 
wherein each category of data defines one of the parameter 
kinds. 

40. The machine readable medium of claim 37, wherein: 
said metadata object includes an action method, which 

when applied by a processor, caxises said processor to 
invoke said function; and 
said method in said execution object, when applied, 
causes sakl action method to be applied. 

41. A machine readable medium-having stored thereon., 
sequences of instructions, which when executed by a set of 
one or more processors, cause said set of one or more 
processors to perform the acts of: 

receiving a request to locate a function that provides a 
particular output parameter, wherein each of a plurality 
of metadata objects identify a different function having 
one or more output parameters, said output parameters 
for the different functions collectively defining a set of 
parameter kinds, each parameter kind in said set being 
assigned a unique key, each of said plurality of meta- 
data objects storing the unique keys assigned the output 
parameters of the function they identify; 

locating a first of said plurality of metadata objects that 
stores the unique key for the particular output param- 
eter; and 

creating an execution object that identifies said first 
metadata object, wherein said execution object 
includes^ 

a structure to identify values for a set of one or more 
iiiput parameters to said function identified by said 
first metadata object, and 

a method, which when applied, causes said function 
identified by said first metadata object to be invoked 
using the values identified by said structure as input 
parameters. 

42. The machine readable medium of claim 41, wherein 
each parameter of said functions is of one of a plurality of 
data types each supporting a range of values, wherein 
different data is categorized irrespective of data type, and 
wherein each category of data defines one of the parameter 
kinds. 

43. The machine readable medium of claim 41, wherein 
said sequences of instructions, when executed, cause said set 
of processors to further perform the acts of: 

applying said method from said execution object, wherein 
tx)th said input and output parameters for the different 
functions collectively define said set of parameter 
kinds, each of said plurality of metadata objects storing 
the unique keys assigned the input and output param- 
eters of the fimction they identify, said method from 
said execution object causing the acts o^ 
accessing the key for each input parameter stored in 

said first metadata object; 
attempting to match parameter values associated with 

said execution object to each of the accessed keys; 

and 

executing the function identified by said first metadata 
object using the parameter values associated with the 
execution object as input parameters. 
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44. The machine readable medium of claim 41, wherein 
said attempting further causes the acts of: 

determining parameter values are missing for a set includ- 
ing at least one of the accessed keys. 

locating a set of one or more of said plurality of metadata 
objects that collectively store each of the set of keys for 
output parameters; and 

executing the functions corresponding to the plurality of 
metadata objects to acquire said set of missing param- 
eter values as outputs of the functions; and 

associating the acquired parameter values with first 
execution object. 

45. A machine readable medium having stored thereon 
sequences of instructions, which when executed by a set of js 
one or more processors, cause said set of one or more 
processors to perform the acts of: 

' 'applying a first melHodfrom a 'fire 

first execution object identifying a first of a pluraUty of 
metadata objects, each of said plurality of metadata 
objects identifying a different function, each of said 
functions having input and output parameters, wherein 
one or more parameters for different functions are the 
same, said parameters for the different functions col- 
lectively defining a set of parameter kinds, each param- 
eter kind in said set of parameter kinds being assigned 
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a unique key, each of said plurality of metadata objects 
storing the unique keys assigned the input and output 
parameters of the function they identify, said first 
method causing the acts of, 

accessing the key for each input parameter stored in 
said first metadata object; 

associating with said first execution object a value 
stored as part of a first of a set of context objects that 
was passed, said value stored for use as a first input 
parameter, said set of context objects being stored in 
a first strucmre of a manager object, each of said set 
of context objects to store values for one or more of 
the input parameters to said first function; and 

executing said first function using the parameter values 
associated with the first execution object as input 
parameters. 

- 46. The machine readable medium of claim' 45, wherein- 
said first method further causes the acts o£ 
associating with said first execution object a value stored 
as part of one of said set of context objects identified by 
said manager object as a default context object, said 
value stored for a second input parameter to said first 
function. 
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